[NTLUG:Discuss] Exploring your hardware info

[Chris Cox]

Aack.. forgot to mention lshw, also an excellent tool.  Fits in
category #8 below.  My bad.

Chris Cox wrote:
> Things to look at/use:
> (not all things are on all machines)
> 
> 1. /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!
> 
> 2. /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).
> 
> 
> 3. 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.
> 
> 4. 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.
> 
> 5. 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.
> 
> 6. 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.
> 
> You might get some info out of biosdecode and vpddecode (useful on
> IBM/Lenovo computers).
> 
> 7. 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.
> 
> 8. /etc/sysconfig/hwconf, discover, hwinfo
> 
> 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 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).
> 
> 
> 9. 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!)
> 
> 
> 
>