Bug 323991

add to the kernel command line:
- 'udevinfo' for basic information
- 'udevdebug' for more debugging output

probably some driver waiting for a firmware.

- 'modprobedebug' to see which module is loaded.

udevinfo appears to touch the iwl3945 driver last, although that's no guarantee
that's the one hanging.  Adding udevdebug doesn't appear to tell me anything
else useful.

modprobedebug just tells me lots of stuff about what modules it fails to find,
nothing about what it's actually doing afaict.

do you have iwl3945-firmware installed?

Yes, iwl3945-firmware-2.15.1.5-2, which appears to be the latest one available.

I get this, too, on a X60s. Worked fine before.
Firmware for iwl3945 is available. Disabling the card using the external kill
switch makes udev fast again (and enabling the kill switch makes the card work
fine afterwards).

please remove /etc/udev/rules.d/70-persistent-net.rules and retry

with udev-116

Yes, that fixes the delay.

Can you compare the old and the new persistent net rules that are generated -
what's the difference?

Well, so far there simply is no new file. What should generate one?

udev theoretically should create one on boot. What does the old one look like?

+ ATTR{type}=="1" 
IIRC

initscript udev-post copies it from /dev/.udev/tmp-rules--* to /etc/udev/rules.d 

Yeah, you need the type==1 because otherwise udev will confuse the wmaster
device and the wlan device, and it should _only_ be touching the wlan device. 
wmasterX is not a normal network device.  The problem is that both wmaster0 and
any STA devices created by wmaster0 (like wlan0) have the same MAC address, so
udev has to have the type==1 to figure out which one to really use.  Otherwise,
since wmaster0 is created first, udev will rename wmaster0 to wlan0 and the
rename of wlan0 to whatever will fail.

I've seen this in cases where 70-persistent-net-rules was created before
whatever udev update fixed 75-persistent-net-rules-generator to DTRT with type==1

harald says udev-116 added ATTR{type}==1 to fix this, but rules generated before
that udev update that will have this problem

udev-115-5... had the fix... but as always, rawhide can eat babies. F7 -> F8 works

ok, the real fix was in  /etc/udev/rules.d/75-persistent-net-generator.rules,
where a whitelist was added.

# device name whitelist
KERNEL!="eth*|ath*|wlan*[0-9]|ra*|sta*|ctc*|lcs*|hsi*",
GOTO="persistent_net_generator_end"

and the ATTR{type}==<origtype> was added to the match rule in
70-persistent-net-rules

The old file looked like this:

---------------------------------------
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x8086:0x109a (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:16:d3:32:bc:a6", NAME="eth0"

# PCI device 0x8086:0x4227 (ipw3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:18:de:ca:a6:b7", NAME="eth1"

# USB device 0x9710:0x7830 (MOSCHIP usb-ethernet driver)
SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:13:3b:00:01:bb", NAME="eth2"

# PCMCIA device 0x000a:0x015f (airo_cs)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:07:85:92:53:c9", NAME="eth3"
-----------------------------------

As said, a new file was not generated, but I found this in
/dev/.udev/tmp-rules--70-persistent-net.rules:

----------------------------------------
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x8086:0x109a (e1000) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:16:d3:32:bc:a6", ATTR{type}=="1", NAME="eth0"

# PCI device 0x8086:0x4227 (iwl3945) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:18:de:ca:a6:b7", ATTR{type}=="1", NAME="eth1"
-----------------------------------

udev-post would have copied it to /etc/udev/rules.d
is udev-post off? did you not reboot?

chkconfig did not even know about it.
Added it, should run on next reboot.

I updated to udev-116-2.fc8 and removed
/etc/udev/rules.d/70-persistent-net.rules.  The first boot did not stall, but
the next one did.  And I found:

% cat /dev/.udev/tmp-rules--70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x8086:0x109a (e1000) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:16:41:58:57:ac", ATTR{type}=="1", NAME="eth0"

# PCI device 0x8086:0x4227 (iwl3945) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:13:02:70:cf:dd", ATTR{type}=="1", NAME="wmaster0"

re comment #22: strange..
%post
chkconfig --add udev-post

doh.. "/sbin/" missing for chkconfig.

udev-116-3 should fix the chkconfig glitches.

Yeah, I'm calling this one fixed, it appears to be solid for me.