• Home
• About
• Calendar
• How Tos
• Blogs
• Articles
• Forums
• News
• Site Map

Exploring Your Hardware
Chris Cox

The Linux kernel detects hardware quite well, but doesn't really help that much with examining the details of the hardware. Red Hat has kudzu which does an adequate job and openSUSE supplies the awesome hwinfo command which probably does the best job. Apart from this, newer systems have sysfs and often times hal. There are many different ways to look at your hardware and some distributions are much better than others. A plethora of mechanisms, a plethora of commands, files and pseudo files:

Exploring Your Hardware

For good reference, especially with regards to dmidecode and the hwinfo --bios information, take a look at the http://www.dmtf.org site.

Things to look at/use: (not all things are on all machines)

/proc

   procinfo
   /proc/ide/*
   /proc/scsi/scsi
   /proc/driver/*
   /proc/cpuinfo

/proc holds a lot of data and used to hold very specific data occasionally for drivers of all types. But Linux booted them out! I know where I work we find useful info inside the /proc/scsi/qla2xxx file. So, certain drivers may still dump things into /proc.

/proc, as the name implies was originally a place for process data. That's why you'll see a lot of numeric dirs in /proc. These are the process ids of processes on the system. Inside is interesting info about the processes.

Kernel parameters can be adjusted in files find in /sys, but you might be better off using the command sysctl (since even data/locations in /proc/sys are subject to change).

/proc/cpuinfo is still of great use. Other things like /proc/interrupts can help when debugging some kind of interrupt issue.

/proc/cpuinfo on newer kernels will show you things like number of cores (core ids, physical ids). On older kernels, might only show logical processors with little info about physical CPUs.

/proc/scsi/scsi and /proc/ide/* (for older kernels) are great places to find information about the disks on the system.

And there's more... explore!

Sysfs

   /sys, showsysfs.sh, systool
   /sys/block
   /sys/block/*/size
   /sys/block/*/device/*
   /sys/class/*

sysfs, if available is usually mounted at /sys and is where most driver level data is supposed to go. It is an attempt at bringing some order to device information. It's under a great deal of flux. Attributes change names and location. The systool command, when working, is a nice way of getting at data in /sys, but because of sysfs's evolutionary changing info.... it might not work at all. showsysfs.sh is sort of like the "tree" command except that it attempts to show values found inside of files if possible.

You can get showsysfs.sh here: http://endlessnow.com/ten/Source/showsysfs-sh.txt

sysfs is an ok place to examine disk data through /sys/block. You usually get the size of the block device (e.g. a disk) and might be able to get access the vendor and model info as well.

Like /proc is used to get/set kernel parameters, /sys files are places to get/set parameters of interest to drivers. (and as always, you could do something bad... for example echo 1 > delete for a block device might not be what you wanted to do).

Newer version of sysfs have the best information for determining CPU minimum, maximum and current speed. Look at: /sys/devices/system/cpu/cpu*/cpufreq/*_freq

I have found no other accurate way to get the cpu max speed information (just fyi).

SCSI

   lsscsi, sginfo, scsiinfo, scsi_info

Now that we've pretty much left the old ide drivers and things have become unified under the libata driver which renders even IDE devices as /dev/sd* devices, the scsi commands, when available, are great ways of examining storage, which could be anything like disks, cdroms, even tape devices.

Bootup Info

  dmesg, /var/log/boot.log, /var/log/boot.msg

At bootup some interesting messages might appear on the console. dmesg is a peak into the ring buffer. Some systems may capture this to a file on bootup.. because the ring buffer can be cleared/changed.

Bus Info

  lspci, lsusb, lspci -tv

You can get a good look at the PCI bus and the usb bus with these commands. I really like lspci -tv because of its tree presentation.

Network Info

  ifconfig -a, ifstatus
  iwconfig, iwgetid, iwlist
  netstat -rn, netstat -vatun, netstat -i, ip
  /etc/resolv.conf
  /etc/nsswitch.conf
  nslookup, dig, host

Network data is very important... since it's usually what people want to know to track down devices and what they are or are not doing on their network! There is a lot of stuff here. The ifconfig tool is useful for getting information about IPv4 and IPv6 configurations on interfaces. It can show different types of network devices including wired, wireless, token ring, VPN (tunnel devices), etc. Very useful. The iwconfig command shows good information about wireless configuration. The resolv.conf file will show how name-IP queries will be done, might have to look at /etc/nsswitch.conf as well. And of course, name lookups and information, possibly very useful information might be found inside of DNS.

DMI (SMBIOS) Info

  dmidecode

This tries to make sense out of the DMI (SMBIOS) info on your x86 box. The info usually tells us about your hardware. Could contain things like the serial number of your platform. Very useful. Enables you to find things like empty CPU sockets or empty ram sockets, and obviously get info about sockets that are occupied. Both the current speed and max speed information from dmidecode is untrustworthy.

You might get some info out of biosdecode and vpddecode (useful on IBM/Lenovo computers).

HAL, udev

  lshal (hald), udevadm info, udevadm monitor, udevinfo

HAL (sorry Dave) is the Hardware Abstraction Layer, again, this is an attempt to create a database of information about hardware. If you have hald running, you should at least have lshal. You probably also have hal-get-property, hal-set-property and newer implemenations will have hal-find-by-property and hal-find-by-capability.

lshal -m allow you to monitor hal messages (try plugging a usb device while doing this).

Udev on newer distros handles dynamic device creation (no more static /dev entries... hooray!). The udevd daemon makes sure that udev gets the messages about hardware (for hotplugging). Udev CAN be fed a list of devices to create "statically", for those cases where that makes sense (/lib/udev/devices). Have fun with udevadm monitor (old udevmonitor) to monitor events... plug/unplug something and watch!

Other things to play/watch with.... dbus-monitor (for desktops like KDE and Gnome that might use the d-bus). This is apart from "exploring hardware", but lots of fun.

All Around Detection

  kudzu's /etc/sysconfig/hwconf, discover, hwinfo, lshw

Kudzu (on newer Red Hat/Fedora) dumps its data into /etc/sysconfig/hwconf. Debian/Ubuntu's discover is also useful for getting a list of hardware on your system. But, the best detection utility is hwinfo (lshw comes in at a close 2nd) which can not only detect but correlate data to devices, hal information, etc. It's one stop shopping. If ALL distributions used hwinfo, the need for >99% of other techniques would go away (sigh).

Regardless of tool, figuring out the maximum frequency of the cpu's is VERY difficult. These tools will show CURRENT CPU speed at best. And remember that speed can vary between processors now.

Graphical Tools

  hardinfo, kinfocenter

So far, everything has been command line. Which is good for parsing and making sense of data for presentation. But you might want to explore your hardware graphically. The best tool I've found is hardinfo. With hardinfo you get a somewhat correlated view into your system AND even some benchmarks (I have no idea why... but neato nonetheless).

kinfocenter is also nice, but not as complete. Under kinfocenter, Protocols shows the available kio slaves under KDE. On KDE typing sysinfo:/ into konqueor shows some nice info. kio is a fascinating world to explore (e.g. use konqueror and enter applications:/ or fonts:/ or system:/ or settings:/ have fun!)
Today