Waiting for UDev events to be processed

A couple of days ago my netbook started taking too long to start up and giving me timeouts while processing events from UDev.
This happened during the boot auto-detection of devices in my distro of choice, Arch Linux.
I found out that it was related to my wireless adapter, Broadcom BCM4313 and a recent commit to udev.

I will present the issue encountered and a possible solution for it. I will especifically show how to do it under Arch Linux and, finally, I will leave you some useful links.


During the boot I ran into the following bunch of lines:

Loading User-specified Modules                   [DONE]
Waiting for UDev uevents to be processed         [BUSY]udevd[131]: worker [138] timeout, kill it

udevd[132]: seq 1077 '/devices/pci0000:00/0000:00:1c.0/0000:05:00:0' killed

udevd[132]: worker [139] terminated by signal 9 (Killed)

In addition, the boot time was severely hit because the Waiting for UDev uevents to be processed part would take too long and timeout.

In my journey to fix this issue, I first ran lspci to check which device was causing this failure and found out it was my Broadcom BCM4313 wireless adapter:

$ lspci -s 0000:05:00.0
05:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01)

Then, I got the name of the module loaded for my card:

$ lspci -vin -s 0000:05:00.0
05:00.0 Class 0280: Device 14e4:4727 (rev 01)
        Subsystem: Device 185f:051a
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f0100000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: < access denied >
        Kernel driver in use: brcmsmac

Now that I knew the module name was "brcmsmac", I decided to add it to my /etc/rc.conf MODULES section, thus making the adapter already available before the udev detection process.

It worked and my boot time got reduced and more elegant.


If you are having the same problem, you should add the module to your boot init script (/etc/rc.conf is one of the ways in Arch Linux), or you can build a cpio kernel image with the module already bundled (but make sure to, somehow, add the required firmware drivers or it won't work because the initial ramfs can't access the root file system).

I have also researched about this problem and it seems to affect many cards as this was generally caused by a recent commit in UDev. So, the solution is easily portable to other devices and kernel modules, you just need to know what those are first (for instance using lspci and the device ID reported by the boot errors and matching them with a kernel module, like I did above).

Now, in more detail, how to fix this problem in Arch Linux with /etc/rc.conf:

1. Make sure you know the name of the module that is failing detection during the boot, as I explained in the paragraph above;
2. Under root, edit /etc/rc.conf;
3. Find a line stating MODULES=(module1 module2 etc);
4. Inside these brackets put the kernel module of your device/adapter (that you found using lspci -vin -s) , like: MODULES=(mymodule) or MODULES=(othermodule mymodule), if you already have other modules manually declared;
5. In my case, I ended up with: MODULES=(brcmsmac acpi-cpufreq coretemp), where brcmsmac is the module of my Broadcom BCM4313, which comes with the linux kernel since version 2.6.39;
6. When you have edited rc.conf, quit and save it, restart the computer and you should now have a proper clean startup.

To complete, I'm leaving you some related links:

• Editing rc.conf 
• Arch Linux related forum post 
• UDev recent changes

Update of 2012/03/15:

• Arch Linux bug report (very useful link)