Arch Linux

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.

boot is slow, but everything works fine

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.

Same here everything works fine but the boot is very slow

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

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.

I got the same issue, in my case boot is slow, but everything, including wifi, works fine.

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.

I get the same timeout and no noticeable wifi problems beyond https://bugs.archlinux.org/task/27955 (which I dont believe is related, beyond both being related to the buggy broadcom BCM43224 module/driver).

@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.

@tomegun @ntwk: me too!

I used the workaround from http://igordcard.blogspot.com/2012/01/waiting-for-udev-events-to-be-processed.html

I just added brcmsmac to the modules in rc.conf and it resolved the udev issue.

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.

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.

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

@robert: please provide detsils about your device, and the error message.

[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:
/var/log/boot:
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 :(

@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.

http://git.kernel.org/?p=linux/hotplug/udev.git;a=patch;h=43d5c5f03645c4b842659f9b5bd0ae465e885e92

http://git.kernel.org/?p=linux/hotplug/udev.git;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.