Arch Linux

Nice work! On my system, this shaved the UDev processing time from ~7000ms to 164ms and everythin is still functioning properly.

Status? I'd like to see this implemented.

Does this decrease total boot time or just makes udev processing appear to be faster?

Well udev processing time definitely gets faster of course, but as far as total boot time, it appears people get mixed results. The best way is to just try it yourself I guess.

the problem which might happen, is things are not finished and boot process just goes on.
New .30 will introduce fastboot patches which will make module loading even more asynchrous.

I don't know anything about the .30 patches or how module loading changed in the new kernel, but the boot process should not go on if things aren't finished. The settle command is left in the foreground so the whole boot process should basically block until settle is done, or at least that is my understanding of it.

+1
But may I suggest to do the trigger in an separate stat_busy stat_done section. This is because initscripts-extras-fbsplash (AUR) hooks into stat_done after stat_busy "Starting UDev Daemon" doing
/sbin/udevadm trigger --subsystem-match=tty --subsystem-match=graphics
/sbin/udevadm settle
to be able to start the Fbsplash daemon. (See  FS#14808  for discussion on this.) This normally takes around 100 ms to settle because only a few events are triggered at this point by now. When triggering all right after starting udev the advantage gets lost when fbsplash is installed.

Suggested PATCH:
--- etc/rc.sysinit.orig 2009-03-10 22:10:02.000000000 +0100
+++ etc/rc.sysinit 2009-06-25 15:54:10.000000000 +0200
@@ -70,6 +70,13 @@
status "Using static /dev filesystem" true
fi

+# Trigger udev uevents
+if /bin/pidof -o %PPID /sbin/udevd >/dev/null; then
+ stat_busy "Triggering UDev uevents"
+ /sbin/udevadm trigger &
+ stat_done
+fi
+
# Load modules from the MODULES array defined in rc.conf
if ! [ "$load_modules" = "off" ]; then
if [ -f /proc/modules ]; then
@@ -101,11 +108,10 @@
fi
fi

-# run udev uevents
+# Wait for udev uevents
if /bin/pidof -o %PPID /sbin/udevd >/dev/null; then
- stat_busy "Loading UDev uevents"
+ stat_busy "Waiting for UDev uevents to be processed"
udevstart="$(/bin/date +%s%0N)"
- /sbin/udevadm trigger
/sbin/udevadm settle
stat_done
udevend="$(/bin/date +%s%0N)"

I like this a lot, and can't believe I didn't notice it before.

Patch in git here for testing: http://projects.archlinux.org/?p=initscripts.git;a=commit;h=fb1177118b663da6b45021cb0ebdb40741047bac

We had a reason for waiting with the triggering until we processed our own MODULES array: If we want to load modules in a certain order (audio, hard disk controllers, etc) we will destroy that order by moving uevent triggering before our module loading.

Most of those ordering problems can be solved differently though: For hard drives, we have UUIDs, for audio we can set index=N options in modprobe configuration files. Just saying that we must be careful here!

Hmm that is a good catch. I am on the fence about whether or not this is a good enough reason to back out the change.

If we do go forward with this, we will probably need an announcement

Just and idea. Maybe we could avoid triggering critical subsystems early doing
/sbin/udevadm trigger --subsystem-nomatch=subsytem [...]
and then later
/sbin/udevadm trigger --subsystem-match=subsytem [...] ?

I guess we could, but somehow I don't like it. I guess that whole "loading modules in the right order" is stupid anyway, there's better ways to solve those problems.

I agree. Order-dependent modules seems awfully oldschool to me

Okay, we have:

hard drives: UUIDs, labels
network cards: udev rules based on the MAC address
sound cards: index=? module parameter

Anything else that used to be problematic with changing module ordering?

I don't really now, but I could think of any kind of devices depending on the users needs. I think the most clean solution would be getting this together with the modular rc.sysinit aka SIMs from  FS#14569 . This way the user could simply move the trigger to the late point if needed.

> Anything else that used to be problematic with changing module ordering?
big "maybe": multiple videocards? but there is pciid in xorg.conf

Now since I updated the kernel to 2.6.30, snd-hda-intel steals the beeps from pcspkr. (The module loaded at least gets the beeps.) To get around this I have to load snd-hda-intel before the udev stuff. I modified the patch to get steps as follows:
- Load modules from the MODULES array defined in rc.conf
- Trigger udev uevents
- Load modules from a new MODULES2 array defined in rc.conf
- Load standard ACPI modules
- Wait for udev uevents
This way we would only load the ACPI modules and those from the new array MODULES2 concurrent to udev and could keep any critical stuff in MODULES. Looks like so here:
MODULES=(!floppy snd-hda-intel)
MODULES2=(fuse acpi-cpufreq cpufreq_ondemand cpufreq_powersave)

Status of this?
Part of the patch was applied already:
http://projects.archlinux.org/?p=initscripts.git;a=commitdiff;h=fb1177118b663da6b45021cb0ebdb40741047bac

Kurt, can you please provide a patch against git: http://projects.archlinux.org/?p=initscripts.git

Patch against git. (Untested though because I use a custom rc.d script to work around the problem now.)

Hmm, the only thing left to implement is the MODULES/MODULES2 thing. I'm not too sure I want to do this. Can you give me specific examples as to what problems this solves?

The only one I know about is the snd-hda-intel pc-beep against pcspkr race. I don't know if more modules loading order problems exist that can't be solved by other means. (As said above, I can live without the patch. Just reloading pcspkr does the trick.)

Well, wouldn't specifying those modules in order in the existing MODULES line solve this? Even if udev loads one or both, a reload of both modules would solve it, right? Or do you mean an actual unload/load?

More to the point though, this seems a bit like a work around for module bugs to me than anything else. I'm sure there's a way, with module params, to tell snd-hda-intel to not touch the pcspkr

I don't like the MODULES2 idea.
The PC speaker beep problem is something not worth to add extra var.
See the bottom of this section: http://wiki.archlinux.org/index.php/ALSA#Set_the_default_sound_card
that appeared after http://bugs.archlinux.org/task/12454
Another PC beep related problem was described in this thread: http://www.archlinux.org/pipermail/arch-general/2009-July/006678.html
but it cannot be solved my modules loading order.

I am not aware of any other (not PC speaker related) problems that might warrant adding MODULES2.
brain0 already listed solutions for hard drives and network cards above (http://bugs.archlinux.org/task/12706#comment45987)

@Aaron: I really meant unloading and loading again. I agree it's a bug in snd-hda-intel - discussed that on tha ALSA devel list 6 weeks abo. Result was something like: "If you don't like the behavior of snd-hda-intel change the config and build your own kernel." The module option you describe was my expectation too, but there is no such.

@Roman:
modinfo snd-pcsp
modinfo: could not find module snd-pcsp

Because I already found another workaround, my vote on this is now: +-0

@Kurt: I believe ALSA devs referred to the option that was mentioned in this thread: http://www.archlinux.org/pipermail/arch-general/2009-July/006678.html
as for module name - probably it was changed :-/

@Roman: I agree to yout 1st point.
2nd point: http://bugs.archlinux.org/task/14958 says it was removed.
grep CONFIG_SND_PCSP /var/abs/core/kernel26/config
# CONFIG_SND_PCSP is not set
I think this is kind of a ALSA sound card driver for the PC speaker. But what I talk about here is the PC beep (console bell or sound from beep binary) which can go thru snd-hda-intel to the stereo jacks since 2.6.30 instead of thru pcspkr to the built in speaker. snd-hda-intel is actually stealing the functionality from module pcspkr.

yes, this is because of CONFIG_SND_HDA_INPUT_BEEP=y in our kernel (btw, it produced a VERY annoying sound, but this is now fixed by upstream)

Anyway, we've got a little offtopic here,
I think the report can be closed as Implemented now.

@brain0: regarding http://bugs.archlinux.org/task/12706#comment45987
input devices were mentioned in http://bugs.archlinux.org/task/15828

Also problems with blacklisting were mentioned in http://bugs.archlinux.org/task/15829
not sure what this has to do with the patch applied.

For me the beep sound from ALSA was ok. But I can not hear it if my speakers are switched off. ;-/
I agree the report can be closed since fixing weird kernel bugs isn't really the primary scope of initscripts. :-)

What's the status on this? Implemented?