Waiting for UDev uevents to be processed waits for 180s

Svenstaro · 2010-04-11 20:02:25

Since upgrading to kernel 2.6.33 my laptop takes 180s to pass udev on booting. It times out and gives me

udevadm settle - timeout of 180 seconds reached, the event queue contains:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:33/PNP0A05:00/PNP0401:00 (942)

and then boots normally. In the booted system I'm not missing any functionality nor did I notice any odd behavior.

A few other people on this forum were having the same issue and I tried applying the posted tips in those topics but to no avail. I've tried disabling KMS and enabling it in early/late start but that didn't get me different results.

dmesg shows an error:

INFO: task modprobe:3236 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
modprobe D 00000000fffffff4 0 3236 3024 0x00000000
ffff880076981c88 0000000000000082 0000000000000001 0000000000000000
ffff880076981c68 ffffffff811cc0e0 0000000000000000 ffffffff816c4218
ffff880076981c94 ffff880076981fd8 ffff880076980000 ffff880076980000
Call Trace:
[<ffffffff811cc0e0>] ? ida_get_new_above+0xb0/0x220
[<ffffffff8135b19d>] schedule_timeout+0x22d/0x360
[<ffffffff81189d3e>] ? create_dir+0x6e/0xc0
[<ffffffff8135ca1d>] __down+0x6d/0xb0
[<ffffffff8127b380>] ? __driver_attach+0x0/0xa0
[<ffffffff8107872c>] down+0x3c/0x50
[<ffffffff8127b3d1>] __driver_attach+0x51/0xa0
[<ffffffff8127b380>] ? __driver_attach+0x0/0xa0
[<ffffffff8127a8f8>] bus_for_each_dev+0x68/0x90
[<ffffffff8127b0c9>] driver_attach+0x19/0x20
[<ffffffff8127a0ad>] bus_add_driver+0xcd/0x2d0
[<ffffffff8127b718>] driver_register+0x78/0x140
[<ffffffff8123b57c>] pnp_register_driver+0x1c/0x20
[<ffffffffa07c650b>] parport_pc_init+0x44b/0x502 [parport_pc]
[<ffffffff81077e09>] ? up_read+0x9/0x10
[<ffffffffa07c60c0>] ? parport_pc_init+0x0/0x502 [parport_pc]
[<ffffffff81002047>] do_one_initcall+0x37/0x1a0
[<ffffffff8108ed17>] sys_init_module+0xd7/0x250
[<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
tpm_tis 00:0b: tpm_transmit: tpm_send: error -62
INFO: task modprobe:3236 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
modprobe D 00000000fffffff4 0 3236 3024 0x00000000
ffff880076981c88 0000000000000082 0000000000000001 0000000000000000
ffff880076981c68 ffffffff811cc0e0 0000000000000000 ffffffff816c4218
ffff880076981c94 ffff880076981fd8 ffff880076980000 ffff880076980000
Call Trace:
[<ffffffff811cc0e0>] ? ida_get_new_above+0xb0/0x220
[<ffffffff8135b19d>] schedule_timeout+0x22d/0x360
[<ffffffff81189d3e>] ? create_dir+0x6e/0xc0
[<ffffffff8135ca1d>] __down+0x6d/0xb0
[<ffffffff8127b380>] ? __driver_attach+0x0/0xa0
[<ffffffff8107872c>] down+0x3c/0x50
[<ffffffff8127b3d1>] __driver_attach+0x51/0xa0
[<ffffffff8127b380>] ? __driver_attach+0x0/0xa0
[<ffffffff8127a8f8>] bus_for_each_dev+0x68/0x90
[<ffffffff8127b0c9>] driver_attach+0x19/0x20
[<ffffffff8127a0ad>] bus_add_driver+0xcd/0x2d0
[<ffffffff8127b718>] driver_register+0x78/0x140
[<ffffffff8123b57c>] pnp_register_driver+0x1c/0x20
[<ffffffffa07c650b>] parport_pc_init+0x44b/0x502 [parport_pc]
[<ffffffff81077e09>] ? up_read+0x9/0x10
[<ffffffffa07c60c0>] ? parport_pc_init+0x0/0x502 [parport_pc]
[<ffffffff81002047>] do_one_initcall+0x37/0x1a0
[<ffffffff8108ed17>] sys_init_module+0xd7/0x250
[<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
tpm_tis 00:0b: tpm_transmit: tpm_send: error -62
parport_pc 00:0a: activated
parport_pc 00:0a: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 5, dma 1 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
lp0: using parport0 (interrupt-driven).

so I put !parport_pc into my rc.conf modules. It then still hangs on booting but doesn't show any kind of udev debug message anymore.

lspci:

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 03)
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc M71 [Mobility Radeon X2100] (rev ce)
06:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
0a:04.0 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
0a:04.1 CardBus bridge: O2 Micro, Inc. Device 7175 (rev 21)
0a:04.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01)
0a:04.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller (rev 01)
0a:05.0 CardBus bridge: O2 Micro, Inc. OZ601/6912/711E0 CardBus/SmartCardBus Controller (rev 40)
0a:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link)

I'm quite clueless here, please help.

Last edited by Svenstaro (2010-04-12 03:12:54)

Svenstaro · 2010-04-12 01:56:53

Kernel 2.6.34-rc3 shows the same problems. Kernel 2.6.32 is alright. I guess this isn't the kind of bug I can sit out then. How can I debug more verbosely? What is the meaning of the device path the udev spits out while booting?

Querying the device gets me this:
udevadm info --path=/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:33/PNP0A05:00/PNP0401:00 --query=all

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:33/PNP0A05:00/PNP0401:00
E: UDEV_LOG=0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:33/PNP0A05:00/PNP0401:00
E: MODALIAS=acpi:PNP0401:
E: SUBSYSTEM=acpi

Last edited by Svenstaro (2010-04-12 03:28:02)

Nepherte · 2010-04-12 10:55:51

I actually like to believe this is a tpm (trusted platform module) issue, see tpm_tis in the log you provided). I have encountered the same problem with my laptop. Adding !tpm_tis and !tpm to the MODULES array in rc.conf solved the 180s delay. The tpm driver in the kernel is still not in a decent working state and has been for a long while now.

Last edited by Nepherte (2010-04-12 10:56:35)

Gen2ly · 2010-04-13 05:44:24

Nepherte, very nice. Had this problem too and fixed the wait time. ... Hope I don't need this modules .

Svenstaro · 2010-04-14 20:04:40

That worked! Nepherte, you are now officially my most awesome person for this week.

nicklas · 2010-06-02 09:47:58

Nepherte wrote:

I actually like to believe this is a tpm (trusted platform module) issue, see tpm_tis in the log you provided). I have encountered the same problem with my laptop. Adding !tpm_tis and !tpm to the MODULES array in rc.conf solved the 180s delay. The tpm driver in the kernel is still not in a decent working state and has been for a long while now.

You're awesome! A friend of mine from the University have had the same problem, and we have been debugging for hours now. This solves the problem.

Thanks!

Arch Linux

#1 2010-04-11 20:02:25

Waiting for UDev uevents to be processed waits for 180s

#2 2010-04-12 01:56:53

Re: Waiting for UDev uevents to be processed waits for 180s

#3 2010-04-12 10:55:51

Re: Waiting for UDev uevents to be processed waits for 180s

#4 2010-04-13 05:44:24

Re: Waiting for UDev uevents to be processed waits for 180s

#5 2010-04-14 20:04:40

Re: Waiting for UDev uevents to be processed waits for 180s

#6 2010-06-02 09:47:58

Re: Waiting for UDev uevents to be processed waits for 180s

Board footer