Bug 243737 - udev starts very slowly.
Summary: udev starts very slowly.
Alias: None
Product: Fedora
Classification: Fedora
Component: udev   
(Show other bugs)
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-11 16:25 UTC by Ari Tilli
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version: kernel-2.6.21-1.3228.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-14 20:19:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Ari Tilli 2007-06-11 16:25:23 UTC
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):

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.
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
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 06:50:30 UTC
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 16:58:37 UTC
Will do modprobedebug later (no reebot now ;) ), though I found this.

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.


Note You need to log in before you can comment on or make changes to this bug.