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 =======================
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.
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.