BEDTIME READING-MODPROBE

From Mike Andrew

UNDERSTANDING INSMOD KERNELD AND MODPROBE

December 99
Reliable for Linux Kernels 2.2.x and generally 2.0x
Module loading appears to cause a lot of unnecessary agony. The following  should clear up some of it.


Any single module, particularly specific device driver modules (soundblaster e.g.) rely on higher level modules to also be loaded. These higher level modules, in turn, generally rely on even higher level modules in order to operate.

Unfortunately, many (mini) HOWTOS are out of date. They do not account for newer linux kernels. Read on...

The inappropriate use of insmod.

insmod does one thing, it loads a specific module. If that module requires, or depends on another module it will fail.

In the bad old days, you had to 'insmod' each module in a specific sequence to get your world to work. You generally achieved this by writing a script-list inside /etc/modules.conf (caldera) or /etc/conf.modules (redhat). The use of script lists generally, and the deliberate invocation of insmod specifically, is no longer required.

The (slightly) appropriate use of modprobe.

Modprobe does all the hard work for you. It recursively loads all dependant modules (and dependant dependants) until the original request can be satisfed. You have no reason to *ever* use insmod, as it is called automatically by modprobe (many more times than you imagine).

Using modprobe, you have no need to know of the esoterically named dependant modules, nor the sequence they need to be loaded in.

However, the only requirement (and personal use) of modprobe is for you to TEST load a module requiring paramaters. Thus
modprobe sb io=0x220, irq=7

Much linux HOWTO documentation will either reccommend you preload

insmod sound
etc.

This is NOT necessary, causes confusion, and should be avoided. It was true at the time of the HOWTO. Not now.

Kerneld

Kerneld, and it's replacement kmod, is a kernel daemon that spends it's life trying to satisfy requests from the kernel proper for modules that are not yet loaded. This is quite reasonable if you only occaisonally look at a cdrom file system (eg), the appropriate module (alias iso9660) will automatically load at the appropriate time.

COAS

Under Caldera (and in a similar mechanism with Redhat). Even the use of modprobe is not required. The paramaters used for modprobe loading can be appropriately installed under COAS->kernel->load. The two benefits are that the module will be installed appropriately at boot time without you worrying further, AND, the module will be loaded by kmod (kerneld) at the appropriate time otherwise.
There is NO practical use of insmod.


The only appropriate use of modprobe is for you to do an initial test and debug of the driver before finally consigning the paramaters to COAS (or the equiv in redhat).

WHEN THINGZ GO BANG

The *only* cause of modprobe failing in order of least frequency

1) the module is already loaded
rmmod <whatever>

2) the module requested, or, a dependant module is NOT in the appropriate place on your system, or not there at all.

If insufficient detail is available at the konsole 'cannot load xxxx.o', 'module xxxx,o not found' look in
tail -50 /var/log/messages

you *will* find the xxxx.o message there.

Do a
locate xxxxx.o

If that module is not found type in as a final check
updatedb

Make some coffee and type in locate xxx.o again

If it is still not found, go find it on an ftp site, because sure as hell, you haven't installed it.

3) The doozy

*The* cause of modprobe failure is bad paramaters.  Wildly guessing 'modprobe sb io=999 irq=66' will give wild results and will be appropriately complained about in /var/log/messages

Documentation, for *the* module is *always* found in two (2) locations

/usr/src/linux/Documentation/drivers/whatever/README
/usr/src/linux/drivers/whatever/device


Here's the good news. If you get ANY complaints from modprobe, everything but the driver is working. So focus on the problem with the driver. Everything else is ok and your system is  setup correctly.

searchSearch Index