Bug 5481

Summary:	INFO: task udevd:81 blocked for more than 120 seconds.
Product:	Mageia	Reporter:	Bjarne Thomsen <bjarne.thomsen>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Normal	CC:	mageia, rwobben, thierry.vignaud, tmb
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	udev	CVE:
Status comment:
Attachments:	Bug 5481/messages file

Description Bjarne Thomsen 2012-04-19 06:04:54 CEST

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.

Comment 1 Manuel Hiebel 2012-04-19 09:13:54 CEST

a bug or no ?

CC: (none) => thierry.vignaud, tmb

Thierry Vignaud 2012-04-19 09:39:28 CEST

CC: (none) => mageia
Source RPM: mgaonline-2.77.32-1 => udev

Comment 2 Colin Guthrie 2012-04-19 11:13:43 CEST

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?

Comment 3 Colin Guthrie 2012-04-19 11:27:47 CEST

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)

Comment 4 Colin Guthrie 2012-04-19 11:53:15 CEST

Also are you running vboxdrv on that kernel?

Comment 5 Bjarne Thomsen 2012-04-19 18:36:00 CEST

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

Comment 6 Colin Guthrie 2012-04-19 19:27:58 CEST

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

Comment 7 Bjarne Thomsen 2012-04-19 21:28:49 CEST

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

Comment 8 Bjarne Thomsen 2012-04-20 14:25:32 CEST

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.

Comment 9 Bjarne Thomsen 2012-04-20 14:55:15 CEST

Created attachment 2049 [details]
Bug 5481/messages file

Comment 10 Thierry Vignaud 2012-04-20 15:04:46 CEST

Comment on attachment 2049 [details]
Bug 5481/messages file

There's nothing related there

Comment 11 Colin Guthrie 2012-04-22 14:00:52 CEST

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?

Comment 12 Bjarne Thomsen 2012-04-23 09:37:03 CEST

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?

Comment 13 Marja Van Waes 2012-05-26 13:08:59 CEST

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

Comment 14 roelof Wobben 2013-01-03 20:25:44 CET

Please report whether this bug is still valid for Mageia 2 or Cauldron

Thanks :)

Cheers,
Roelof

CC: (none) => r.wobben

Comment 15 Bjarne Thomsen 2013-01-04 12:22:38 CET

No, it is not valid. I had forgotten all about it.

roelof Wobben 2013-01-04 12:24:07 CET

Status: NEW => RESOLVED
Resolution: (none) => INVALID