Bug 323991

Summary: udevsettle takes 33 seconds to do nothing
Product: [Fedora] Fedora Reporter: Adam Jackson <ajax>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: notting, redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-23 12:01:48 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 235703    

Description Adam Jackson 2007-10-08 19:01:56 EDT
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.
Comment 1 Harald Hoyer 2007-10-09 05:23:15 EDT
add to the kernel command line:
- 'udevinfo' for basic information
- 'udevdebug' for more debugging output
Comment 2 Harald Hoyer 2007-10-09 05:43:24 EDT
probably some driver waiting for a firmware.
Comment 3 Harald Hoyer 2007-10-09 05:44:50 EDT
- 'modprobedebug' to see which module is loaded.
Comment 4 Adam Jackson 2007-10-09 11:49:45 EDT
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.
Comment 5 Harald Hoyer 2007-10-10 03:35:12 EDT
do you have iwl3945-firmware installed?
Comment 6 Adam Jackson 2007-10-11 12:03:18 EDT
Yes, iwl3945-firmware-2.15.1.5-2, which appears to be the latest one available.
Comment 7 Ralf Ertzinger 2007-10-17 06:51:44 EDT
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).
Comment 8 Harald Hoyer 2007-10-18 06:59:44 EDT
please remove /etc/udev/rules.d/70-persistent-net.rules and retry
Comment 9 Harald Hoyer 2007-10-18 07:00:01 EDT
with udev-116
Comment 10 Ralf Ertzinger 2007-10-18 12:08:39 EDT
Yes, that fixes the delay.
Comment 11 Bill Nottingham 2007-10-18 13:21:36 EDT
Can you compare the old and the new persistent net rules that are generated -
what's the difference?
Comment 12 Ralf Ertzinger 2007-10-18 13:26:53 EDT
Well, so far there simply is no new file. What should generate one?
Comment 13 Bill Nottingham 2007-10-18 13:30:46 EDT
udev theoretically should create one on boot. What does the old one look like?
Comment 14 Harald Hoyer 2007-10-18 13:31:36 EDT
+ ATTR{type}=="1" 
IIRC
Comment 15 Harald Hoyer 2007-10-18 13:32:56 EDT
initscript udev-post copies it from /dev/.udev/tmp-rules--* to /etc/udev/rules.d 
Comment 16 Dan Williams 2007-10-18 13:35:44 EDT
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
Comment 17 Dan Williams 2007-10-18 13:37:53 EDT
harald says udev-116 added ATTR{type}==1 to fix this, but rules generated before
that udev update that will have this problem
Comment 18 Harald Hoyer 2007-10-18 13:55:10 EDT
udev-115-5... had the fix... but as always, rawhide can eat babies. F7 -> F8 works
Comment 19 Harald Hoyer 2007-10-18 14:16:03 EDT
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
Comment 20 Ralf Ertzinger 2007-10-18 14:20:35 EDT
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"
-----------------------------------
Comment 21 Harald Hoyer 2007-10-18 14:31:35 EDT
udev-post would have copied it to /etc/udev/rules.d
is udev-post off? did you not reboot?
Comment 22 Ralf Ertzinger 2007-10-18 14:42:16 EDT
chkconfig did not even know about it.
Added it, should run on next reboot.
Comment 23 Adam Jackson 2007-10-18 14:47:25 EDT
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"
Comment 24 Harald Hoyer 2007-10-18 14:54:15 EDT
re comment #22: strange..
%post
chkconfig --add udev-post
Comment 25 Harald Hoyer 2007-10-18 15:36:54 EDT
doh.. "/sbin/" missing for chkconfig.
Comment 26 Harald Hoyer 2007-10-18 15:59:22 EDT
udev-116-3 should fix the chkconfig glitches.
Comment 27 Adam Jackson 2007-10-23 12:01:48 EDT
Yeah, I'm calling this one fixed, it appears to be solid for me.