Bug 243737

Summary:	udev starts very slowly.
Product:	[Fedora] Fedora	Reporter:	Ari Tilli <ari.tilli>
Component:	udev	Assignee:	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 20:19:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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):
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 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.
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.