Bug 243737 - udev starts very slowly.
udev starts very slowly.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-11 12:25 EDT by Ari Tilli
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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.

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