Description of problem: udevsettle is waiting for Godot. Version-Release number of selected component (if applicable): udev-115-4.20070921git.fc8 How reproducible: Oh baby. Steps to Reproduce: 1. Boot rawhide. 2. http://people.freedesktop.org/~ajax/bootchart-udev-despair.png 3. Loss. This on a Thinkpad T60p running rawhide as of October 8. This could easily be a kernel bug with some driver just not finishing init or something, but I don't know where to start looking.
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.