Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#28154 - [udev]worker timeout

Attached to Project: Arch Linux
Opened by GS (aslmaswd) - Sunday, 29 January 2012, 14:42 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 13 March 2012, 23:25 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Tom Gundersen (tomegun)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 11
Private No


Sun Jan 29 22:32:04 2012: :: Waiting for UDev uevents to be processed [BUSY] udevd[148]: worker [159] timeout, kill it
Sun Jan 29 22:32:04 2012:
Sun Jan 29 22:32:04 2012: udevd[148]: seq 1237 '/devices/pci0000:00/0000:00:1c.1/0000:03:00.0' killed
Sun Jan 29 22:32:04 2012:
Sun Jan 29 22:32:04 2012: udevd[148]: worker [159] terminated by signal 9 (Killed)
Sun Jan 29 22:32:04 2012:
Sun Jan 29 22:32:04 2012: [DONE]

Additional info:
* udev 179-1

This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 13 March 2012, 23:25 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#27938 
Comment by Tom Gundersen (tomegun) - Sunday, 29 January 2012, 20:22 GMT
This is either a kernel bug (if boot is slow, but everything works fine), or a duplicate of  FS#28097  (if your ipw2200 chip does not work). If it is neither of those, please provide more info.
Comment by GS (aslmaswd) - Monday, 30 January 2012, 05:47 GMT
boot is slow, but everything works fine
Comment by Gereon Schomber (IncredibleLaser) - Friday, 03 February 2012, 15:35 GMT
I can confirm this bug on my notebook. udev 180-1, linux 3.2.2-1, wlan is "Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)" working as intended.
Comment by Edric Ladent-Milaret (Edc) - Saturday, 04 February 2012, 08:52 GMT
Same here everything works fine but the boot is very slow
Comment by TEAM ALPHA (team-alpha) - Monday, 06 February 2012, 17:56 GMT
I got the same problem on my thinkpad x121e (also the wifi device)
i added the driver to the modules array in rc.conf, and it worked (i used "rtl8192ce")
Comment by Stefan Förster (HotblackDesiato) - Tuesday, 07 February 2012, 19:48 GMT
I have the same problem with my SMC EZ Connect™ g Wireless Cardbus Adapter (PCMCIA, prism chip set) on my IBM ThinkPad T23. I have to remove the adapter an re-insert it into the PCMCIA slot to get wifi. Rollback to the previous setup with udev-175, mkinicpio etc. helped.

It is a shame that this "improvement" of udev breaks a lot of wifi kernel modules that have been working for years. Both my notebook and my wife's ThinkPad X41 (kernel module ipw2200) now have non-functional wifi with the current Arch Linux. I would rather have expected that udev changes would be synced with changes to kernel modules. I have no sympathy at all with such an approach.
Comment by Sébastien Grenier (sgrenier) - Tuesday, 07 February 2012, 19:51 GMT
I got the same issue, in my case boot is slow, but everything, including wifi, works fine.
Comment by Tom Gundersen (tomegun) - Tuesday, 07 February 2012, 20:29 GMT
Thanks to everyone for reporting this, and sorry for the problems. We thought the last problems had been solved when we moved the package, but there are obviously some left (ipw2200 in particular).

I have worked a bit with upstream to make ipw2200 work, but we have not been successful so far (mainly due to a lack of hardware). Good (but not great) news is that the kernel devs started looking for a new ipw2200 maintainer after I contacted them about this problem, so maybe we'll get a proper fix eventually.

Reverting to udev-175 is not an option, as a lot of other packages that rely on newer udevs have been released since.

What I intend to do when time permits is to create a broken kernel module so that I can reproduce this myself (I don't have the right hardware), and then I'll hopefully be able to create a proper revert. This is not as simple as it seems, as the naive revert did not work for those who tested it.

@Stefan: if your lack of sympathy could be converted into a well-tested patch, I'd be happy to apply it.
Comment by Ben Mehne (ben0mega) - Thursday, 09 February 2012, 00:22 GMT
I get the same timeout and no noticeable wifi problems beyond (which I dont believe is related, beyond both being related to the buggy broadcom BCM43224 module/driver).
Comment by Lewis Pike (ntwk) - Thursday, 09 February 2012, 02:55 GMT
@tomegun: I have ipw2200 hardware and I would be willing to contribute time testing possible fixes as well as providing any debugging information you may need.
Comment by Antonio Muñoz (tomby) - Thursday, 09 February 2012, 06:16 GMT
@tomegun @ntwk: me too!
Comment by ryan nunes (noons) - Friday, 10 February 2012, 04:49 GMT
I used the workaround from

I just added brcmsmac to the modules in rc.conf and it resolved the udev issue.
Comment by Thiago Coutinho (thiagoc) - Friday, 02 March 2012, 13:28 GMT
I have a Dell Vostro 3300 with a Broadcom Wireless card:

12:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n (rev 01)

Adding brcmsmac to the modules array in rc.conf doesn't fix this bug.

linux 3.2.8-1
udev 181-2

EDIT: sorry for the noise, it was fixed with the brcmsmac on modules array in rc.conf. I think it was a typo in the name of module.

EDIT2: actually it works sometimes, but not always.
Comment by Faelar (Faelar) - Friday, 02 March 2012, 15:20 GMT
I was having the same hang in VirtualBox (although with usd, not wireless). Today I removed 'e4rat', changed mkinitcpio.conf to use 'lzop' compression instead of 'xz', and did a 'mkinitcpio -p linux'. My boot looks OK so far, it might be a clue... or not at all, so in doubt I posted it here.
Comment by Robert (nazwa) - Saturday, 10 March 2012, 13:51 GMT
I'm not sure whether my bug is related because I DON'T have WiFi card. I use ethernet pcmcia adapter on a very old notebook (pentium 3 mobile).

Errors and symptoms are identical - slow boot, after boot everything works fine, same message in /var/log/boot
Comment by Tom Gundersen (tomegun) - Saturday, 10 March 2012, 14:47 GMT
@robert: please provide detsils about your device, and the error message.
Comment by Robert (nazwa) - Saturday, 10 March 2012, 15:43 GMT
[sorry for duplicate comment]

I solved the issue by putting module pcnet_cs (which is the driver for pcmcia card) in the MODULES array in rc.conf

Error message:
Sat Mar 10 16:24:38 2012: :: Waiting for UDev uevents to be processed [BUSY] udevd[110]: worker [114] timeout, kill it
Sat Mar 10 16:24:38 2012:
Sat Mar 10 16:24:38 2012: udevd[110]: seq 1232 '/devices/pci0000:00/0000:00:0b.1/1.0' killed
Sat Mar 10 16:24:38 2012:
Sat Mar 10 16:24:38 2012: [DONE]

udev 181-2, kernel (default) 3.2.9-1-ARCH #1 SMP PREEMPT

My device is old surecom ethernet pcmcia card (on the old toshiba notebook). Apropriate module is, as i've mentioned, pcnet_cs.

Details are showed by the result of lspcmcia:

Socket 1 Bridge: [yenta_cardbus] (bus ID: 0000:00:0b.1)
Configuration: state: on ready: unknown
Voltage: 5.0V Vcc: 5.0V Vpp: 0.0V
Socket 1 Device 0: [pcnet_cs] (bus ID: 1.0)
Configuration: state: on
[io 0x0300-0x030f flags 0x100]
[io 0x0310-0x031f flags 0x108]
[mem 0x00000000 flags 0x200]
[mem 0x00000000 flags 0x200]
[mem 0x00000000 flags 0x200]
[mem 0x00000000 flags 0x200]
Product Name: TAMARACK Ethernet A 004743118001
Identification: function: 6 (network)
prod_id(1): "TAMARACK" (0xcf434fba)
prod_id(2): "Ethernet" (0x00b2e941)
prod_id(3): "A" (0x01db7106)
prod_id(4): "004743118001" (0x430c5620)

I'm sorry if my comment doesn't qualify as a bug :(
Comment by Tom Gundersen (tomegun) - Monday, 12 March 2012, 10:26 GMT
@Lewis: thanks for the offer to help! (And sorry for not seeing your comment until now).

What we need is to figure out a working revert of the removal of the TIMEOUT special casing. My assumption is that reverting the following two patches should make this work as before, but I had a tester claiming it did not. Checking this again would be a useful first step.;a=patch;h=43d5c5f03645c4b842659f9b5bd0ae465e885e92;a=blobdiff_plain;f=udev/udevd.c;h=63b4fd7ad26c33a28b17c097cc819461aa692d43;hp=1e12eb38acce556d8262e039b1273a40af6b3743;hb=57c6f8ae5f52a6e8ffc66a54966346f733dded39;hpb=43d5c5f03645c4b842659f9b5bd0ae465e885e92

Anyone with the right hardware who are willing to test this (even if you don't know how to apply patches etc), can ping me in #archlinux-projects.