Description of problem: Apr 19 05:34:14 localhost mgaapplet[1675]: ### Program is starting ### Apr 19 05:34:20 localhost mgaapplet[1675]: running: ionice -p 1675 -n7 Apr 19 05:35:15 localhost kernel: [ 240.580119] INFO: task udevd:81 blocked for more than 120 seconds. Apr 19 05:35:15 localhost kernel: [ 240.580122] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 19 05:35:15 localhost kernel: [ 240.580124] udevd D 00000008 0 81 1 0x00000000 Apr 19 05:35:15 localhost kernel: [ 240.580145] f08bfed0 00000082 2648652e 00000008 00000003 f10a0000 00000008 c0748e80 Apr 19 05:35:15 localhost kernel: [ 240.580150] c0748e80 25f0d24a 00000008 f1a06e80 f0856480 f10a0000 c013bb6c f08bfe9c Apr 19 05:35:15 localhost kernel: [ 240.580155] c011f209 00000000 00000000 00000000 f08af004 f08bff00 c04b9045 f08af004 Apr 19 05:35:15 localhost kernel: [ 240.580160] Call Trace: Apr 19 05:35:15 localhost kernel: [ 240.580188] [<c013bb6c>] ? irq_exit+0x5c/0xa0 Apr 19 05:35:15 localhost kernel: [ 240.580197] [<c011f209>] ? smp_apic_timer_interrupt+0x59/0x90 Apr 19 05:35:15 localhost kernel: [ 240.580213] [<c04b9045>] ? apic_timer_interrupt+0x31/0x38 Apr 19 05:35:15 localhost kernel: [ 240.580216] [<c04b7645>] schedule+0x35/0x50 etc. etc. And then it repeats again and again. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
a bug or no ?
CC: (none) => thierry.vignaud, tmb
CC: (none) => mageiaSource RPM: mgaonline-2.77.32-1 => udev
Looks like an APIC problem in ther kernel according to the backtrace. We'd probably need a full backtrace tho' if you can supply one (preferably as a .txt attachment so it's easier to read) Does this happen reliably - i.e. can you reproduce?
Also I've been asked to ask you: After the notice, how much longer does it stay blocked? Can you check wchan while it's blocked? (/proc/<pid>/wchan)
Also are you running vboxdrv on that kernel?
Let me se if I understand: 1) I copy from the beginning of the boot until it happens, if it happens again. 2) How do I check /proc/1675/wchan ? After I have logged in? 3) I will look for vboxdrv
Just to answer your points: 1) We'll need the bit starting "INFO: task udevd...." until the end of the Call Trace section. 2) Yup, just use the pid of the main udev process. I think this is 81 in your above example, but not 100% sure, ("ps aux | grep udev" will show you all udev processes, you can probably grab the right pid from that and/or confirm the number in the log corresponds to the right process). 3) Basically, "lsmod | grep vbox" Cheers :)
Unfortunately, there was no INFO: task udevd:81 blocked when I booted. I had updated from beta3 to current cauldron The reason I looked in the first place was the long boot time. I would have to wait and see if it happens again. As for lsmod|grep vbox vboxvideo 12539 1 drm 208242 2 vboxvideo vboxguest 199921 5
It has just happened again; but this time it dropped to debug shell. I had to stop it from outputting "task udevd:82 blocked..." by echo 0 > /proc/sys/kernel/hung_task_timeout_secs to prevent the text to disappear out of the screen. It all starts by dracut Warning: Cancelling resume operation. Device not found. dracut Warning: Unable to process initqueue dracut Warning: "/dev/disk/by-uuid/49d1..bla..bla" does not exist and just now the vbox screen went black, so I cannot type the rest. It cannot find the disk, but why? I will try to re-boot to se what it wrote in messages.
Created attachment 2049 [details] Bug 5481/messages file
Comment on attachment 2049 [details] Bug 5481/messages file There's nothing related there
To me this sounds like it could be related to faulty hardware or a strange driver bug. If it's happening inside dracut, then this is presumably before vboxdrv or anything too crazy is loaded (this is on bare metal right?) We use udev to detect drives... does /dev/sda* or /dev/hda* show up inside the dracut shell? If so, can you do: udevadm test /block/sda and udevadm test /block/sda/sda1 (adjusting the name accordingly) Do either of those work? And do they show the ID_FS_UUID attribute for the root disk?
No it is running inside virtualbox 4.0 in Mageia-1 using a virtual disk. I suspect that it could be a bug in virtualbox, but I have been running both ubuntu and debian in the same vbox. The problem is intermittent. How do I drop into a dracut shell, in case it happens again?
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Please report whether this bug is still valid for Mageia 2 or Cauldron Thanks :) Cheers, Roelof
CC: (none) => r.wobben
No, it is not valid. I had forgotten all about it.
Status: NEW => RESOLVEDResolution: (none) => INVALID