cvs commit: hints hardware-detection.txt
tushar at linuxfromscratch.org
tushar at linuxfromscratch.org
Mon Dec 8 21:32:50 PST 2003
tushar 03/12/08 22:32:50
Added: . hardware-detection.txt
Revision Changes Path
AUTHOR: Alexander E. Patrakov <semzx at newmail dot ru>
LICENSE: GNU GPL
SYNOPSIS: Automatic Detection of PCI and USB Hardware in LFS
Sometimes you don't know exactly what type of hardware you have and don't
want to guess the correct module. Now you don't have to guess. Software
needed to automatically detect your hardware at boot time is described in
PREREQUISITES: This hint works for LFS >=4.0, with or without devfs, with
2.4 or 2.6 kernel.
Currently, LFS users must either compile all relevant device drivers into
the kernel statically or write some magic lines in /etc/modules.conf.
Either way, they need to know exactly what hardware thay have. This
information is not always available for notebooks and "rebranded" devices.
Fortunately, most of your hardware can be autodetected at boot time. One
drawback of my solution is that it doesn't work at all with ISA cards.
Another drawback is a two-second delay during the boot process. The third
drawback is that modules for not-so-often used hardware are loaded at boot
time, not on first use as it is the case for the variant with modules.conf.
It has been reported that following this hint results in tons of
(possibly bogus) messages about overcurrent from USB modules on some
computers. I will not be responsible for any damaged hardware.
If you see or don't see these messages, please mail the author the output of
lspci and lsusb commands so that he can formulate the exact conditions
leading to these messages in the future versions of this hint.
HAVE YOU READ THE BIG WARNING ABOVE?
To make your computer detect hardware automatically, install the following
Instructions are in the BLFS book. You will need the patch named
pciutils-2.1.11-pcimodules-1.patch from the patches project since we will
use the pcimodules command.
This command should output the list of modules needed to support your PCI
cards, based on the contents of /lib/modules/`uname -r`/modules.pcimap file.
Test your installation of pciutils:
a) run the lspci command and see if the output is correct. At home I get the
00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x]
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus
Master IDE (rev 06) 00:07.2 USB Controller: VIA
Technologies, Inc. USB (rev 1a)
00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:0b.0 Communication controller: Lucent Microelectronics LT WinModem (rev
00:0d.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A
[FM801] (rev b2)
00:0d.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801 game
port] (rev b2)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX]
b) run the pcimodules command and see if the results make any sense for the
I have the following output:
If you want the pci.ids file to be in /usr/share/misc rather than in
/usr/share, use the patch named pciutils-2.1.11-sharedir-1.patch
2) [optional] usbutils
This package contains lsusb and usbmodules commands. They are the USB
equivalents of the lspci and pcimodules commands from pciutils. The package
is, strictly speaking, not needed because the hotplug script will parse
/proc/bus/usb/*/* files and detect USB devices even without usbutils. That
works for me. But the authors of the hotplug package write that the process
will be more reliable with usbutils.
Explanation of the last two commands: the libusb libraries installed by the
usbutils package are not used. The relevant code is linked statically into
lsusb and usbmodules programs. A newer, incompatible version of libusb is
available separately and it provides files /usr/lib/libusb-0.1.* and
/usr/include/usb.h. Other applications such as SANE use that newer version.
If you want the usb.ids file to be in /usr/share/misc rather than in
/usr/share, add the --datadir=/usr/share/misc switch to the ./configure
Now test the package:
- insert modules that correspond to your USB controller. If in doubt, consult
the output of the pcimodules command. E.g.:
- mount the usb filesystem:
mount -t usbfs usbfs /proc/bus/usb
- run the lsusb command. On my system, the output is:
Unknown line at line 1809
Duplicate HUT Usage Spec at line 2650
Bus 001 Device 001: ID 0000:0000 Virtual Hub
Bus 001 Device 002: ID 05d8:4002 Ultima Electronics Corp. Lifetec LT9385
(really this is Mustek 1200 UB plus)
- run the usbmodules command for one of the devices, e.g.:
usbmodules --device /proc/bus/usb/001/002
The output on my computer is:
Note that the usb.ids file shipped with the usbutils package is old and
incomplete. This is not a problem because the usbmodules command uses
another file, /lib/modules/`uname -r`/modules.usbmap to map devices to
The scripts in this package react to the hotplug events sent by kernel, and
also to the synthetic "coldplug" events at boot time. They use programs from
pciutils and usbutils to load the correct modules and execute specific
The scripts contained in the hotplug package have to be modified a bit to
conform to LFS standards. Do the following with etc/rc.d/init.d/hotplug:
a) [required] After the line "start|restart|status)" add:
[ -d /var/run/usb ] || mkdir -m 700 /var/run/usb
b) [required] Remove all lines that refer to /var/lock/subsys/hotplug - the
/var/lock/subsys directory is not used in LFS.
c) [cosmetic] Change all lines of the form "$RC $1" or "$RC start" to:
HW=`basename $RC .rc | tr [:lower:] [:upper:]`
echo "Detecting $HW hardware..."
(or $1 start)
Do similar changes to lines of the form "$RS stop":
HW=`basename $RC .rc | tr [:lower:] [:upper:]`
echo "Stopping $HW hardware support..."
Now copy all scripts contained in the hotplug package to their final places
and chown them to root:root. Make the following symlinks:
ln -s ../init.d/hotplug /etc/rc.d/rc3.d/S15hotplug
ln -s ../init.d/hotplug /etc/rc.d/rc4.d/S15hotplug
ln -s ../init.d/hotplug /etc/rc.d/rc5.d/S15hotplug
4) Linux kernel
Compile one kernel supporting all hardware on all target computers, with
lots of modules. Also compile ALSA, DRI and whatever packages that contain
modules. Don't forget the following:
a) Compile in "Support for hot-pluggable devices"
b) Compile in support for "Preliminary USB filesystem". My kernel has this
compiled in statically. It has been reported that compilation of it as a
module does not work as expected. I am too lazy to verify this.
c) Never compile your root device and filesystem as modules.
d) Don't forget that sometimes there are two drivers for the same device.
Compile only one of them, ok blacklist all modules except one (see below).
Comment out all lines of the form "alias eth0 8139too" that specify the
driver explicitly. The modules will be loaded from the hotplug script. Note
that the order of your ethernet adapters may change if you have two of
Add the following line:
usbfs /proc/bus/usb usbfs defaults 0 0
FIXME: maybe this doesn't work on old computers without USB.
Add names of modules that you don't want to load automatically. Good
- duplicate drivers (e.g. e100 vs eepro100)
- unstable drivers (e.g. scanner in linux-2.4.21, my scanner worked well only
with libusb; the problem went away in 2.4.22)
- framebuffers (e.g. rivafb) if you primarily use X
- often-misdetected modules (e.g. i810_rng gives false positives)
d) Specific actions for specific hardware (aka quirks)
(you are lucky if you don't need them)
If you have anything specific to do with your USB hardware, create a script
in /etc/hotplug/usb. E.g., before one-endpoint scanners were well supported
by the scanner kernel module, I had to change permissions on the pseudofile
in /proc/bus/usb corresponding to my Mustek 1200 UB Plus scanner, so that I
could work with it as a user, not as root. This script accepts the name of
the pseudofile in the DEVICE environment variable. The complete
documentation concerning other variables is at the top of
/etc/hotplug/usb.agent. So I wrote this:
cat >/etc/hotplug/usb/mustek1200ubplus <<"EOF"
chmod 666 $DEVICE
chmof 755 /etc/hotplug/usb/mustek1200ubplus
Then add a line to /etc/hotplug/usb.usermap, as described in the comment at
the top of file. I added the following (sorry for wrapping):
mustek1200ubplus 0x0003 0x05d8 0x4002 0x0000 0x0000
0x00 0x00 0x00 0x00 0x00
The idVendor and idProduct fields (0x05d8 and 0x4002) can be taken from the
output of lsusb. The first field is a logical OR of the following flags:
So my line basically says "Check for vendor and product IDs and ignore
everything else. If they are equal to 0x05d8 and 0x4002, the execute
the mustek1200ubplus script".
Of course, now there is no this line because linux-2.4.22 supports this
scanner well without libusb.
Apparently there is some support for such specific actions (e.g. firmware
loading) for PCI hardware. See the top of /etc/hotplug/pci.agent. I can't
say more because I don't need such actions.
Reboot and see if all needed modules are loaded by the hotplug script.
In my case, LT WinModem remains undetected. I resorted to
having a line for that modem in /etc/modules.conf:
alias /dev/tts/LT0 lt_serial
A different approach is to create a script named /etc/hotplug/hidden.rc that
executes modprobe commands for each undetectable module. Or you can edit
Manual editing of /lib/modules/`uname -r`/modules.pcimap is also one of the
ways to deal with misdetections when the wrong module gets loaded (the other
way is blacklisting the wrong module).
- Add autoconfiguration of the X server
- Add something for ISA PNP cards
2003-12-04: Initial submission
More information about the hints