Avoiding autoloading

On a faster computer, autoloading might not be a big deal. But on this 300Mhz Pentium II, it causes a considerable boot delay.

The problem, as I understand it, is that the autoloading sequence first senses the modules you need, then loads them in the correct order.

Which is fine, except on a machine like this — a laptop, with no real opportunities for hardware changes — it’s really only needed once. After that, if I run into a hardware switch, autosensing the modules it needs would probably be nice. But that’s one boot out of a thousand, and I’m just weird enough to convince myself that I need a rebuild if I get a new piece of hardware. I’m a glutton for punishment. … :roll:

Disabling autoloading does cause one problem, though: Modules have to be inserted in the proper order for some of them to work. It’s just like dependencies. If you try to start something and it’s missing another piece, it’s going to crap out on you. Only this time you’ll be left without a mouse. Or video. Or a functioning hard drive.

I installed hwdetect via pacman, and started it with the –show-modules flag. This is the output, on my nifty Dell Latitude CPi A300XT:

AGP : agpgart intel-agp
PATA : ata_generic
SATA : ata_piix
USB : usbcore uhci-hcd
NET : ppp_generic slhc ieee80211_crypt hermes hostap hostap_cs orinoco orinoco_cs
INPUT : evdev pcspkr psmouse serio_raw tsdev
PCMCIA : pcmcia pcmcia_core rsrc_nonstatic yenta_socket
SOUND : snd-mixer-oss snd-pcm-oss snd-page-alloc snd-pcm snd-timer snd snd-ac97-bus snd-ac97-codec snd-nm256 soundcore
OTHER : cdrom lp ppdev rtc i2c-piix4 i2c-core parport parport_pc pci_hotplug shpchp

Unless I’m mistaken, those are all the modules this system needs to function properly.

I’ve seen another way of doing this since I tried it, a couple of days ago. This is modified slightly from a seemingly unrelated post on the Arch forums:

modprobe -a --show-depends $(find /sys/devices/ -name modalias -exec cat {} + ) | sort -u

I think the net effect is the same, although the second method does leave in the paths to the modules. For my purposes, the first method was preferable. I copied that into a text file and made it into a raw list of modules.

Then I did a little Googling and tried to figure out what each module did, and whether or not I wanted to keep it. Some were easy; I don’t use a modem, so I suspected ppp_generic of being useless to me. It was, and was thrown out as a result. Same with parport and parport_pc, and some others.

To test it, I blacklisted the module in rc.conf but kept autoloading enabled, and rebooted. If things worked, it was discarded. If not … well, as an example, I thought serio_raw would be pointless, but when I blacklisted it and rebooted with autoloading still enabled, I suddenly had no external mouse. So you can’t be sure. Keep autoloading on for a while and blacklist to test.

(It’s worth mentioning at this point that there’s a load_modules=off flag that might save you if you’re having problems booting after tweaking your modules. It’s a one-time emergency override that prevents any modules from loading, which means almost nothing will work … but on the other hand, you should be able to get back on your feet.)

After about 20 minutes of searching and Googling, I had two lists: needed and unneeded.

agpgart intel-agp ata_generic ata_piix usbcore uhci-hcd ieee80211_crypt hermes hostap hostap_cs orinoco orinoco_cs evdev pcspkr psmouse serio_raw pcmcia pcmcia_core rsrc_nonstatic yenta_socket snd-mixer-oss snd-pcm-oss snd-page-alloc snd-pcm snd-timer snd snd-ac97-bus snd-ac97-codec snd-nm256 soundcore cdrom rtc i2c-piix4 i2c-core pci_hotplug

shpchp parport parport_pc lp ppdev tsdev ppp_generic slhc

I blacklisted all the unneeded modules, and rebooting worked fine. And yet, if I copy those needed modules into the MODULES=() line, I still ended up with a borked system. That’s the dependencies playing tricks on you again.

I don’t know if there’s a better way to do this, and if there is, I’d love to hear about it. But my solution was to search through the modules.dep file, which has a canonical list of modules available on your system, sorted in insertion order.

Open nano -w /lib/modules/`uname -r`/modules.dep. It’ll probably be about 1450 lines long, if not longer. So be patient on an older system.

Use CTRL+W (the “Where Is” search) to search for the name of the module with a .ko suffix. Make sure you’re on the line that lists that module, then press CTRL+C, which will show you the line count.

Keep a list of all those modules and the lines they appear on. Something like this:

agpgart 943
intel-agp 949
ata_generic 1108
ata_piix 1086
usbcore 1179
uhci-hcd 498
ieee80211_crypt 843
hermes 861
hostap 856
hostap_cs 858
orinoco 861
orinoco_cs 848
evdev 737
psmouse 736
serio_raw 719
pcmcia 839
pcmcia_core 839
rsrc_nonstatic 1002
yenta_socket 1007
snd-mixer-oss 249
snd-pcm-oss 249
snd-page-alloc 249
snd-pcm 264
snd-timer 264
snd 264
snd-ac97-bus 266
snd-ac97-codec 267
snd-nm256 289
soundcore 289
cdrom 663
rtc 980
i2c-piix4 1055
i2c-core 1055
pci_hotplug 682

It’s an ugly list, but when you’ve sorted all those into the order determined by their line numbers, you have a perfect, concise and sorted list of all the modules your machine needs — that you want, that is.

Now go back into the rc.conf file, turn off autoloading and insert those lines into the MODULES=() line. In my case, it looked like this:

MODULES=(snd-mixer-oss snd-pcm-oss snd-page-alloc snd-pcm snd-timer snd snd-ac97-bus snd-ac97-codec snd-nm256 soundcore uhci-hcd cdrom pci_hotplug serio_raw psmouse evdev pcmcia pcmcia_core ieee80211_crypt orinoco_cs hostap hostap_cs hermes orinoco agpgart intel-agp rtc rsrc_nonstatic yenta_socket i2c-piix4 i2c-core ata_piix ata_generic usbcore)

(Don’t ask me why the sound stuff is at the front. I just work here.) You can comment out the MOD_BLACKLIST line now, unless you feel safer with your unneeded modules in there. If autoloading is off and you’ve inserted the modules you want manually, they shouldn’t ever be touched.

On reboot, my machine was working great — external mouse, touchpad, video, audio, even wireless. No problems whatsoever.

If I was better at scripting, perhaps I could come up with a more elegant way of doing this than to output a list, sort it, search-search-search, sort-sort-sort, and then rebuild it into a shape that rc.conf wants.

But for now, I’m content: My boot time went from 46.13 seconds to 42.24! :D

About these ads

7 Responses to “Avoiding autoloading”


  1. 1 NerdyShinobi 2007/01/28 at 3:36 AM

    Thanks for explaining this little bit here. I can strip WinXP to the bone with Nlite and disable services until the cows come home, but in Linux, I’m literally a babe in the woods. I have a feeling that the wife’s laptop is geting the royal Arch treatment soon. Or at least a true stripped Ubuntu following your Edgy Speed guide.

  2. 2 vsk 2008/05/31 at 8:16 AM

    This is very interesting!
    I just ran hwdetect –modules, and here is the output;

    MODULES=(dock cdrom agpgart intel-agp intel-rng hid usbhid i2c-algo-bit i2c-i801 i2c-i810 i2c-core evdev ff-memless pcspkr psmouse serio_raw pci_hotplug shpchp ac97_bus snd-mixer-oss snd-pcm-oss snd snd-page-alloc snd-pcm snd-timer snd-ac97-codec snd-intel8x0 soundcore pata_acpi ata_generic scsi_mod ata_piix 8139cp 8139too mii usb-storage usbhid usbcore ehci-hcd uhci-hcd sd_mod sr_mod)

    How can I be sure that it is safe to turn off autoload with the modules in this order?

    * I’m scared to reboot!

    – Arch User

  3. 3 vsk 2008/05/31 at 8:22 AM

    * Sorry for posting twice.. Couldn’t edit the first one!

    When you lsmod, are the modules with a Used By value of 0 safe to remove from the MODULES list? I would assume so…

    Thanks!

  4. 4 Andrei 2008/12/04 at 8:24 PM

    Thanks. But no thanks.

    My Arch boots in 15 seconds.

    Should I waste several days of my life to gain 3-5 seconds? I do not think so.

    Come on, it is nearly 2008 and even the cheapest PCs are screamingly fast.

  5. 5 K.Mandla 2008/12/04 at 8:38 PM

    Well, considering you can do the same thing now with hwdetect --modules >> /etc/rc.conf, it certainly doesn’t take several days to do this.

    And come on, it is nearly 2009 and even the cheapest PCs are more expensive than the ones I own now, and mine run plenty fast. ;)

  6. 6 The same guy 2009/11/28 at 7:04 AM

    Yeah, my arch box boots in 12 secs but I need to strip down my list of modules so that I can build my stock kernel.

  7. 7 Archlinux 2010/04/08 at 8:59 PM

    It has almost no effect now with the recent module loading technique, which I don’t know more about, but showed up with my results that the booting time was the same with “MOD_AUTOLOAD=yes” *and* with “MOD_AUTOLOAD=no” (where I even stripped down my unneeded modules).

    So my vanilla kernel-arch shows up 10 secs in bootchart although my boot is a little slower than that =). I used a lot of stuff to get this “10 sec boot” but the one that affected the most was the “Arch quick-init” implementation.


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




Welcome!



Visit the Wiki!

Some recent desktops


May 6, 2011
Musca 0.9.24 on Crux Linux
150Mhz Pentium 96Mb 8Gb CF
 


May 14, 2011
IceWM 1.2.37 and Arch Linux
L2300 core duo 3Gb 320Gb

Some recent games


Apr. 21, 2011
Oolite on Xubuntu 11.04
L2300 core duo 3Gb 320Gb

Enter your email address to subscribe to this blog and receive notifications of new posts.

Join 405 other followers

License

This work is licensed under the GNU Free Documentation License. Please see the About page for details.

Blog Stats

  • 3,962,710 hits

Archives


Follow

Get every new post delivered to your Inbox.

Join 405 other followers

%d bloggers like this: