Bug 243737

Summary: udev starts very slowly.
Product: [Fedora] Fedora Reporter: Ari Tilli <ari.tilli>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 7   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-2.6.21-1.3228.fc7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-14 16:19:24 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Ari Tilli 2007-06-11 12:25:23 EDT
Description of problem:
Upgraded to FC7 from FC6 now udev is very slow to start,
i.e. takes about minute, though eventually starts.
This is maybe driver problem, not udev ??

Version-Release number of selected component (if applicable):
udev-106-4.fc7

How reproducible:
Every boot in my machine. I tried to boot with udev-debug flag on but this
resulted to far too much information.

Additional info: dmesg shows some timeout errors, that might show the cause.
1)...
audit(1181587052.210:3): policy loaded auid=4294967295
drivers/usb/input/hid-core.c: usb_submit_urb(ctrl) failed
drivers/usb/input/hid-core.c: timeout initializing reports
input: Logitech Logitech Attack 3 as /class/input/input3
input: USB HID v1.10 Joystick [Logitech Logitech 
2)... and
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x4)
ata5: failed to recover some devices, retrying in 5 secs
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x4)
ata5.00: limiting speed to UDMA/33:PIO3
ata5: failed to recover some devices, retrying in 5 secs
ata5.00: qc timeout (cmd 0xef)
ata5.00: failed to set xfermode (err_mask=0x4)
ata5.00: disabled
3)...
BUG: warning at kernel/softirq.c:138/local_bh_enable() (Tainted: P      )
 [<c042b0cf>] local_bh_enable+0x45/0x92
 [<c06002bd>] cond_resched_softirq+0x2c/0x42
 [<c059adf3>] release_sock+0x4f/0x9d
 [<c05c670d>] tcp_sendmsg+0x90b/0x9f9
 [<c05dec95>] inet_sendmsg+0x3b/0x45
 [<c0598731>] sock_aio_write+0xf6/0x102
 [<c04754ee>] do_sync_write+0xc7/0x10a
 [<c0436e71>] autoremove_wake_function+0x0/0x35
 [<c0475d47>] vfs_write+0xbc/0x154
 [<c0476342>] sys_write+0x41/0x67
 [<c0404f70>] syscall_call+0x7/0xb
 =======================
Comment 1 Harald Hoyer 2007-06-12 02:50:30 EDT
You may also try "modprobedebug" on the kernel command line.

I think it's 2) which takes the most time...

You can try and unload the modules, then load them by hand and see, if you find
it then.
Comment 2 Ari Tilli 2007-06-13 12:58:37 EDT
Will do modprobedebug later (no reebot now ;) ), though I found this.
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03088.html

I have also LITE-ON LTR-40125S CDRW , so it seems this is a known libata
problem.  Though I do not know if this patch is in Fedora or Kernel.orgs 
kernel, or if it is waiting for inclusion.
http://readlist.com/lists/vger.kernel.org/linux-kernel/45/228948.html

Ari.