Bug 433933

Summary: Occasional extra long delays starting udev
Product: [Fedora] Fedora Reporter: Bruno Wolff III <bruno>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: vonbrand, zcerza
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-23 06:11:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Bruno Wolff III 2008-02-22 02:26:41 EST
Occasionally after the "Starting udev:" prompt there is a delay on the order of a minute instead of the normal roughly 5 seconds before proceding.


Version-Release number of selected component (if applicable):
udev-118-1.fc9.i386

How reproducible:
Maybe something on the order of 25%.

Steps to Reproduce:
1.reboot
2.
3.
  
Actual results: After the starting udev prompt there is an usually long delay.


Expected results: After the prompt is displayed there should only be a short pause before moving on.


Additional info:The raid arrays are raid 1 using pata drives and the fs is ext3.
Comment 1 Zack Cerza 2008-03-03 12:41:54 EST
udev-118-5.fc9.i386 is taking several minutes here, and timing out. Sometimes,
the system never ends up booting.

This started happening with rawhide kernels after -28. I'm now on
kernel-2.6.25-0.82.rc3.git2.fc9.i686 .

There's nothing funny about this system; it's a Thinkpad X41 with simple non-LVM
disk partitions.
Comment 2 Horst H. von Brand 2008-03-05 09:37:23 EST
udev-118-5.fc9.i386 here, now kernel-2.6.25-0.90.rc3.git5.fc9.i686 on dual-core
i686, symptoms as in comment 1. Machine is Toshiba Tecra, has a USB mouse
plugged in. No RAID, LVM for handling the disk.

And no, udev doesn't take anywere near 5 seconds to start, more like 20 (unless
it times out). And here it times out roughly 50% of the time.

This doesn't show on x86_64 dual core desktop (also rawhide, roughly the same
packages installed)
Comment 3 Horst H. von Brand 2008-03-09 11:53:32 EDT
Yesterday I had to reboot 3 times before udev started OK
Comment 4 Horst H. von Brand 2008-03-11 18:08:55 EDT
Now I measured udev startup time (2nd try, when it started OK). A full 35
seconds (!).
Comment 5 Harald Hoyer 2008-03-12 14:39:45 EDT
try to add "udevinfo" or "udevdebug" to the kernel command line
Comment 6 Harald Hoyer 2008-03-12 14:40:34 EDT
you may hit ctrl-c, if it takes too long also...
Comment 7 Harald Hoyer 2008-03-13 09:17:43 EDT
hmm, you can also try to identify the culprit in the udev rules files.
just move away some rules files from /etc/udev/rules.d and boot into single mode

first try all files that do not belong to udev or initscripts. if the problem
persists, try the *persistent* files. 
Comment 8 Harald Hoyer 2008-03-13 10:48:16 EDT
oh, and you may try to blacklist modules, to see, if the delay comes from a module

just add to /etc/modprobe.conf:

blacklist <modulename>
Comment 9 J├│hann B. Gu├░mundsson 2008-03-13 11:34:40 EDT
See if it's still there after rawhide 20080313 updates.
I was experince the similar thing and then it seemed to be related to selinux
and udev you can add selinux=0 to the boot parameter and see if you takes as
long ( I just got stuck on udev,if I had selinux enabled and in
disabled,permissive or enforcing mode I could not get passed udev, after rawhide
20080313 updates it seems to be fixed.
Comment 10 Harald Hoyer 2008-03-13 11:42:03 EDT
with recent rawhide udev-118-8.fc9 you may also try to boot with "udevnopersist"
in the kernel command line.
Comment 11 Harald Hoyer 2008-03-13 12:49:05 EDT
udev-118-9.fc9 now has support for a "modprobedebug" kernel command line, which
may identify a kernel module causing the delay.
Comment 13 Bruno Wolff III 2008-03-15 21:47:33 EDT
I am still seeing some variability of the pauses with udev-118-5.fc9.i386. I
don't think the worst case is as bad as it was previously. I'll install 118-9
and add modprobedebug to grub.conf and keep an eye on it.
 
Comment 14 Bruno Wolff III 2008-04-06 00:51:53 EDT
Things seem mostly better now. I haven't seen a long hang in a long time. No
single module seems to pause for more than 2 seconds and most appear to take no
noticeable time.
Comment 15 Harald Hoyer 2008-04-07 10:06:13 EDT
should I close this bug then?
Comment 16 Bruno Wolff III 2008-04-07 12:57:16 EDT
I think it is OK to. If I see it happen again I can reopen it. My only
hesitation is that I don't know what fixed it.