Linux Hardware Diagnostics

Hardware Diagnostics

* In order to configure a Driver for some Hardware, we first need to identify it properly.
* Often, the name of the product we bought is unknown, or is too generic.
* What we are most interested in, is the name of the manufacturer and model of the chips (chip-sets) found on our Hardware Device…
* … Because this is what the Driver eventually communicates with.

The lspci Command

* Allows us to identify the type of Hardware we have on our system.
* Provided that these are PCI cards (not older ISA cards).

Example output of lspci

/sbin/lspci
00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3189
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device b168
00:0a.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
00:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
00:0c.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3177
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C (rev 10)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX440] (rev a3)

A modem, 2 sound cards, 2 network cards, a USB interface, an IDE controller and a screen controller.

Verification Via The /proc Directory

* The /proc directory is a virtual directory, allowing direct interaction with the running Linux Kernel.
* When we try to print one of its files, the Kernel generates its contents on-the-fly. There are no real disk files under this directory.
* Some files interesting for Hardware diagnostics (view them with cat ):
o /proc/interrupts – a list of interrupt numbers (IRQs) currently in use by different Drivers.
o /proc/ioports – a list of I/O addresses currently in use by Drivers.
o /proc/pci – info about PCI Devices.
o /proc/cpuinfo – info about our CPU.

The /dev directory

* The standard location for all Device files in the system…
* …But one can create Device files in other directories (e.g. in RedHat’s installation process, the Device files for the hard disks are created in the /tmp directory).
* Examples of conventional file names:
o hda – first (a) IDE Device (hard disk, CDROM).
o hdb3 – 3rd (3) partition of second (b) IDE Device (must be a hard disk. CDROMs have no partitions).
o ttyS0 – first serial port (“COM1”).
o sda1 – 1st (1) partition of first (a) SCSI Device (hard-disk, an emulated SCSI Device, etc.).
o lp0 – first parallel port (LPT1).

Character Device Vs. Block Device

* A Character (‘c’) Device is one with which the Driver communicates by sending and receiving single characters (bytes, octets).
* A Block (‘b’) Device is one with which the Driver communicates by sending entire blocks of data.
* Examples for Character Devices: serial ports, parallel ports, sounds cards.
* Examples for Block Devices: hard disks, USB cameras, Disk-On-Key.
* For the user, the type of the Device (block or character) does not matter – you just care that this is a hard disk partition or a sound card.

Listing Loaded Modules With lsmod

In order to see the list of currently loaded Modules, use the lsmod command:

/sbin/lsmod
Module Size Used by Not tainted
ppp_synctty 6368 0 (unused)
ppp_async 8032 1
ppp_generic 23692 3 [ppp_synctty ppp_async]
slhc 6220 0 [ppp_generic]
ipt_LOG 4384 19 (autoclean)
ipt_TCPMSS 3168 1 (autoclean)
iptable_nat 19668 1 (autoclean)
ip_conntrack 20268 1 (autoclean) [iptable_nat]
iptable_filter 2464 1 (autoclean)
ip_tables 13632 6 [ipt_LOG ipt_TCPMSS iptable_nat iptable_filter]
vfat 11804 1 (autoclean)
fat 36184 0 (autoclean) [vfat]
ext3 64800 3 (autoclean)
jbd 47924 3 (autoclean) [ext3]
emu10k1 60832 1
ac97_codec 12256 0 [emu10k1]
sound 69260 0 [emu10k1]
soundcore 6212 7 [emu10k1 sound]
mousedev 5024 1
hid 20608 0 (unused)
input 5696 0 [mousedev hid]
ehci-hcd 16864 0 (unused)
usb-uhci 24292 0 (unused)
usbcore 71104 1 [hid ehci-hcd usb-uhci]

The /lib/modules Directory

* Contains the Modules for the different Kernel versions we have installed.
* One directory per Kernel, named after the Kernel’s version number.
* Modules are split into directories, based on categories:
o pcmcia – PCMCIA Drivers, for laptops.
o kernel/net – network-related Modules (firewall, extra protocols support, etc.)
o kernel/drivers – Drivers for various types of Hardware (including network Drivers).
o kernel/fs – file-systems support (ext3, vfat, etc.)
o kernel/arch – Architecture-specific support (e.g. Drivers to handle features of a a specific CPU or motherboard).

Loading And Unloading Kernel Modules – insmod/rmmod

* Module loading and unloading may only be performed by root.
* To load a Kernel Module, use the insmod command:

insmod eeprom
Using /lib/modules/2.4.18-17.7.x/kernel/drivers/sensors/eeprom.o

Check with lsmod that the Module was indeed loaded.
* To un-load a Kernel Module, use the rmmod command:

rmmod eeprom

Check with lsmod that the Module was indeed un-loaded.

Handling Kernel Module Dependencies – depmod and modprobe

* Modules could depend on each other. For example, to load the Module ‘lm78’, we need to first load ‘i2c-core’ and ‘i2c-proc’.
* The depmod command builds a list of Module dependencies – i.e. for each Module, which other Modules it needs, in order to load. Run it as:

depmod -a

depmod: *** Unresolved symbols in
/lib/modules/2.4.18-17.7.x/kernel/arch/i386/kernel/longhaul.o
depmod: *** Unresolved symbols in
/lib/modules/2.4.18-17.7.x/kernel/arch/i386/kernel/p4-clockmod.o
depmod: *** Unresolved symbols in
/lib/modules/2.4.18-17.7.x/kernel/arch/i386/kernel/speedstep.o

* In order to have the system take care of these loading dependencies automatically, load a Module using the modprobe command:

modprobe lm78

or, for a more verbose output:

modprobe -v lm78

/sbin/insmod /lib/modules/2.4.18-17.7.x/kernel/drivers/i2c/i2c-core.o
Using /lib/modules/2.4.18-17.7.x/kernel/drivers/i2c/i2c-core.o
Symbol version prefix ”
/sbin/insmod /lib/modules/2.4.18-17.7.x/kernel/drivers/i2c/i2c-proc.o
Using /lib/modules/2.4.18-17.7.x/kernel/drivers/i2c/i2c-proc.o
/sbin/insmod /lib/modules/2.4.18-17.7.x/kernel/drivers/sensors/lm78.o
Using /lib/modules/2.4.18-17.7.x/kernel/drivers/sensors/lm78.o

The /etc/modules.conf file

* Contains ‘default’ parameters for Modules we use often (e.g. network Drivers, sound cards, etc.)
* commonly used lines:
o alias – specifies that a given Module (Driver) should be used for a given Hardware Device. example:

alias eth0 8139too

o options – specifies options to supply to a given Module, when it is loaded. example:

options sb io=0x220 irq=5 dma=1 dma16=0 mpu_io=0x310

* Note: module options may also be supplied as parameters to the insmod and modprobe commands.

Getting Information About A Kernel Module – modinfo

* In order to get information about a Module (author, supported options), we may use the modinfo command.
* For example, information about the ‘mousedev’ Module:

/sbin/modinfo mousedev

filename: /lib/modules/2.4.18-17.7.x/kernel/drivers/input/mousedev.o
description: “Input driver to PS/2 or ImPS/2 device driver”
author: “Vojtech Pavlik “
license: “GPL”
parm: xres int, description “Horizontal screen resolution”
parm: yres int, description “Vertical screen resolution”

* The source code of the Module can also be used to get information about it. In some cases, there are interesting comments at the top of the source file.

Standard Kernel Drivers

* Many Drivers come as part of the distribution’s Kernel. Use Them.
* These Drivers are stored, as we saw, in the /lib/modules/ directory.
* Sometimes, the Module file name will imply about the type of Hardware it supports.
* Often, a search on Google would give the Module’s name, assuming we looked for the chip-set, not for the marketing name of the Hardware.
* Finally, looking on the web page of the company that manufactures the product, or the chip-set, might come up with a Driver. If we’re lucky, this Driver is already part of our Kernel, and we don’t need to download it.

What If Our Driver Is Not Compiled?

* Some Drivers might come as part of our Kernel’s sources, but still not be compiled in the distribution’s default Kernel.
* We can see this by looking for the Driver in the Kernel source tree…
* … Or by reading about its existence on the web, or in the Kernel source documentation (/usr/src/linux/Documentation).
* To compile this Driver, we will need to perform a full Kernel compilation and then compile the Driver.
* Usually, the second time around, we will not need to re-compile the entire Kernel – just the 2nd Driver.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s