udev hangs for 30s after upgrade

Fisaulerod · 2012-01-22 04:21:54

twelveeighty wrote:

Fisaulerod wrote:
I have this:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
I have to add rtl8111? In /lib/modules/3.2.1-1-ARCH/.../wireless/ i have rt2x00, rtl818x, rtlwifi and others....i feel like a dummy u.u
Don't feel bad - it's a bit of a crapshoot to find the right one, unless you're well-versed in driver-speak. I did the following:
Run as root:
> kmod list
And look through the list - mine had entries like this:
...
rtl8192se 88473 0
rtlwifi 91390 1 rtl8192se
...
Which I presumed was my wireless (wifi). Hence the "rtl8192se"...

I run kmod list and there was no wireless driver (the ones i have in the wireless folder)

I tried with rtl818x but it didn't work..i will try with the others

and sorry for my english XD

leonshaw · 2012-01-22 06:32:39

bwat47 wrote:

willbprog127 wrote:
Adding brcmsmac to MODULES in rc.conf fixed the 30 second hang for me, however I still wonder if this is the 'official resolution' to issues like this, or if the developers will fix this problem...surely this kind of workaround is not part of the elegant 'Arch Way', is it?
Its my understanding from the bug report that this is an issue with these effected drivers, and needs to be fixed upstream in the kernel.
https://bugs.archlinux.org/task/27938
(See the last comment)

Yes, my rtl8192se driver also hangs when suspend/hibernate.

meph · 2012-01-22 07:26:12

For people still trying to figure out their driver name:

lspci -v

In the output look for anything that says Wireless, 802.11, Network controller (make sure it's not your ethernet card in this case). If still not sure, pastebin the whole output and link it here, I'm sure somebody will help you identify the correct item.

Anyway, when you know which item is your wifi card, look for Kernel modules in the description of that item, it states the exact name of your module.

For example, mine is:

07:00.0 Network controller: Broadcom Corporation BCM43225 802.11b/g/n (rev 01)
        Subsystem: Foxconn International, Inc. T77H103.00 Wireless Half-size Mini PCIe Card
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at c0800000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: brcmsmac
        Kernel modules: brcmsmac

stolowski · 2012-01-22 08:49:50

I've a Broadcom BCM4313 802.11b/g/n Wireless LAN Controller and I can confirm that adding brcmsmac module to MODULES list fixes the problem for me as well.

Last edited by stolowski (2012-01-22 08:50:12)

tomegun · 2012-01-22 09:30:52

Hi guys, sorry that this has been causing problems.

What is happening is that some kernel drivers are asking udev to load their firmware before their modules have finished loading. This used to work fine because udev gave firmware request special treatment and served them without waiting for anything else.

As of udev-177 this is no longer done. All events are treated the same, and a firmware event that is the child of a module event (which is the case that is causing us problems) is only served once the parent event has finished. In order to avoid dead-locks the modprobe is given a 30 seconds timeout, after which the firmware event can continue to be loaded. This is what you are seeing.

This problem should be solved by fixing the kernel drivers, and I know that at least he netdev guys are aware of it and working on it. If anyone is interested in helping out they should go to the kernel bugzilla/mailinglist.

digitalone · 2012-01-22 16:07:02

tomegun wrote:

Hi guys, sorry that this has been causing problems.
What is happening is that some kernel drivers are asking udev to load their firmware before their modules have finished loading. This used to work fine because udev gave firmware request special treatment and served them without waiting for anything else.
As of udev-177 this is no longer done. All events are treated the same, and a firmware event that is the child of a module event (which is the case that is causing us problems) is only served once the parent event has finished. In order to avoid dead-locks the modprobe is given a 30 seconds timeout, after which the firmware event can continue to be loaded. This is what you are seeing.
This problem should be solved by fixing the kernel drivers, and I know that at least he netdev guys are aware of it and working on it. If anyone is interested in helping out they should go to the kernel bugzilla/mailinglist.

How long have I to wait to see this fixed?

I have this message on startup:
RUN+="socket:..." support will be removed from a future udev release. Please remove it from lib/udev/rules.d/90-hal.rules:2 and use libdev to subscribe to events

What have I to do?

Gusar · 2012-01-22 16:28:01

digitalone wrote:

How long have I to wait to see this fixed?

Several drivers need fixing. Drivers that are being developed by different people. So there's no easy prediction. Could be months (possibly not before linux-3.4 is released). Figure out which kernel module is giving you the issue - wireless drivers being likely candidates - and use the workarounds described in this thread for now.

digitalone wrote:

I have this message on startup:
RUN+="socket:..." support will be removed from a future udev release. Please remove it from lib/udev/rules.d/90-hal.rules:2 and use libdev to subscribe to events

Oooooooooooooouch, it means HAL will stop working at some point in the future!! However, do you actually have something that still uses HAL? It's very likely that you don't, in which case you could simply uninstall HAL.

Last edited by Gusar (2012-01-22 16:37:28)

Fisaulerod · 2012-01-22 16:53:42

meph wrote:

For people still trying to figure out their driver name:
lspci -v
In the output look for anything that says Wireless, 802.11, Network controller (make sure it's not your ethernet card in this case). If still not sure, pastebin the whole output and link it here, I'm sure somebody will help you identify the correct item.
Anyway, when you know which item is your wifi card, look for Kernel modules in the description of that item, it states the exact name of your module.
For example, mine is:
07:00.0 Network controller: Broadcom Corporation BCM43225 802.11b/g/n (rev 01)
        Subsystem: Foxconn International, Inc. T77H103.00 Wireless Half-size Mini PCIe Card
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at c0800000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: brcmsmac
        Kernel modules: brcmsmac

thanks!, i was loading the lan driver ¬¬..brcmsmac worked for me

twelveeighty · 2012-01-22 19:13:03

tomegun wrote:

This problem should be solved by fixing the kernel drivers, and I know that at least he netdev guys are aware of it and working on it. If anyone is interested in helping out they should go to the kernel bugzilla/mailinglist.

I have created Bug 42632 (https://bugzilla.kernel.org/show_bug.cgi?id=42632) - that was my first bug entry in the kernel Bugzilla. I hope they're not going to shred me to pieces, haha.

@tomegun: can you check out my bug report and see if I missed something there?

digitalone · 2012-01-22 21:15:34

Gusar wrote:

Figure out which kernel module is giving you the issue - wireless drivers being likely candidates - and use the workarounds described in this thread for now.

The workaround fixes only udev problem, I still can't load user-specified module at startup having the message showed before.

Gusar wrote:

digitalone wrote:
How long have I to wait to see this fixed?
Several drivers need fixing. Drivers that are being developed by different people. So there's no easy prediction. Could be months (possibly not before linux-3.4 is released).

Months? Am I going to unload the user-specified modules for months?
If there were these problems, why did devs move newer version of udev in core repository?
Couldn't it remain in testing?

Gusar wrote:

digitalone wrote:
I have this message on startup:
RUN+="socket:..." support will be removed from a future udev release. Please remove it from lib/udev/rules.d/90-hal.rules:2 and use libdev to subscribe to events
However, do you actually have something that still uses HAL?

I don't know. How can I figure out that?

Gusar · 2012-01-22 21:24:53

digitalone wrote:

The workaround fixes only udev problem, I still can't load user-specified module at startup having the message showed before.

The message is irrelevant to module loading. It's just a warning that a function HAL is using will be gone in the future. If you have module loading problems (other than the 30s hang issue discussed here), you'll have to explain exactly what those are.

digitalone wrote:

If there were these problems, why did devs move newer version of udev in core repository?

That's a very good question. I asked it myself in another thread. Seems premature to me.

digitalone wrote:

Gusar wrote:
However, do you actually have something that still uses HAL?
I don't know. How can I figure out that?

Start with "pacman -Qi hal" and check the "Required by" line. If nothing is there, uninstall HAL and reboot. If everything still works, cool.

digitalone · 2012-01-22 21:38:36

Gusar wrote:

digitalone wrote:
The workaround fixes only udev problem, I still can't load user-specified module at startup having the message showed before.
The message is irrelevant to module loading. It's just a warning that a function HAL is using will be gone in the future. If you have module loading problems (other than the 30s hang issue discussed here), you'll have to explain exactly what those are.

I get the message, but loading user-specified modules FAILS.
Is that irrelevant?

Sun Jan 22 21:57:32 2012: :: Adjusting system time and setting kernel timezone [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Starting UDev Daemon [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Triggering UDev uevents [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Loading User-specified Modules [BUSY] udevd[154]: RUN+="socket:..." support will be removed from a future udev release. Please remove it fr
Sun Jan 22 21:57:32 2012:
Sun Jan 22 21:57:32 2012: [FAIL]
Sun Jan 22 21:57:32 2012: :: Waiting for UDev uevents to be processed [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Bringing up loopback interface [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Checking Filesystems [BUSY] linux: clean, 229643/5955584 files, 6481627/23800576 blocks
Sun Jan 22 21:57:32 2012: [DONE]
Sun Jan 22 21:57:32 2012: :: Remounting Root [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Mounting Local Filesystems [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Activating Swap [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Configuring Time Zone [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Initializing Random Seed [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Removing Leftover Files [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Setting Hostname: archtoshiba [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Setting Consoles to UTF-8 mode [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Loading Keyboard Map: it [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: :: Saving dmesg Log [BUSY] [DONE]
Sun Jan 22 21:57:32 2012: INIT: Entering runlevel: 5
Sun Jan 22 21:57:33 2012: :: Starting Syslog-NG [BUSY] [DONE]
Sun Jan 22 21:57:33 2012: :: Starting D-BUS system messagebus [BUSY] [DONE]
Sun Jan 22 21:57:33 2012: :: Starting laptop-mode [BUSY] [DONE]
Sun Jan 22 21:57:36 2012: :: Setting cpufreq governing rules [BUSY] ^[[u, cpu^[[u 0^[[u 1^[[
Sun Jan 22 21:57:36 2012: :: Starting wicd [BKGD]
Sun Jan 22 21:57:36 2012: :: Starting acpid [BKGD]
Sun Jan 22 21:57:36 2012: :: Starting crond [BKGD]
Sun Jan 22 21:57:36 2012: :: Starting samba [BKGD]
Sun Jan 22 21:57:36 2012: :: Starting alsa [BKGD]
Sun Jan 22 21:57:36 2012: :: Starting cupsd [BKGD]
Sun Jan 22 21:57:36 2012: :: Starting sensors [BKGD]
Sun Jan 22 21:57:36 2012: :: Starting hddtemp [BKGD]

Gusar · 2012-01-22 21:42:56

Yes, it's irrelevant. Udev events are being triggered, then modules are being loaded. The message has to do with the triggering, not with module loading. Also, the message is harmless. It's a "for your information" message, not an error.

digitalone · 2012-01-22 21:55:42

Gusar wrote:

Yes, it's irrelevant. Udev events are being triggered, then modules are being loaded. The message has to do with the triggering, not with module loading. Also, the message is harmless. It's a "for your information" message, not an error.

Understood, thanks.

Gusar · 2012-01-22 22:34:42

There's still the issue of why you get "FAIL" for module loading. Check this thread, seems relevant for that: https://bbs.archlinux.org/viewtopic.php?pid=1045939

hidefromkgb · 2012-01-22 23:05:54

Well, i`ve got a similar issue here.

The problem seems related, but I`m not sure if it really is.
Still, my machine also hangs for 30 secs, and then i see these messages:

radeon_cp: Failed to load firmware "radeon/R520_cp.bin"
[drm:r100_cp_init] *ERROR* Failed to load firmware!
radeon 0000:01:00:0: failed initializing CP(-2).
radeon 0000:01:00:0: Disabling GPU acceleration
iwl3945 0000:03:00:0: iwlwifi-3945-2.ucode firmware file req failed: -2
iwl3945 0000:03:00:0: iwlwifi-3945-1.ucode firmware file req failed: -2
iwl3945 0000:03:00:0: could not read microcode: -2

If I understand these messages correctly, -2 is an error code, which means ENOENT (file not found).
And right here begins the magic: both

ls /lib/firmware | grep 3945

and

ls /lib/firmware/radeon | grep R520

say that all necessary files are present!
As a result, my video card (Radeon x1700 Mobility) works 12 times slower than it did, according to glxgears, and the wireless module (Intel 3945abg) does not work at all, since ifconfig hangs and refuses to bring up wlan0 interface.

What can I do about it, if I can?

hidefromkgb · 2012-01-23 02:20:36

Hehe, it`s getting curiouser and curiouser
One reboot ago there was a sudden cascade of general protection faults in modprobe, followed by a «kernel BUG» («bug» in capitals).
Unfortunately, I could not find a better solution to capture the debug output than to photograph it, as long as nothing seemed to be functional after the issue. Trying to reproduce the bug gave no effect so far.

Anyway, since I`m experiencing this, can I be of any help in testing kmod, and how?

Last edited by hidefromkgb (2012-01-23 02:26:11)

archman-cro · 2012-01-23 07:44:03

stolowski wrote:

I've a Broadcom BCM4313 802.11b/g/n Wireless LAN Controller and I can confirm that adding brcmsmac module to MODULES list fixes the problem for me as well.

+1 on this. I can confirm that this fixes the issue with BCM4313.

Amancio · 2012-01-23 13:41:09

For me, the trick with MODULES in rc.conf didn't work. What I needed to do:

1. Remove 'rtl8192se' in MODULES in rc.conf (I had added just for test).
2. Add 'blacklist rtl8192se' in /etc/modprobe.d/modprobe.conf
3. Add '/sbin/modprobe rtl8192se' in /etc/rc.local

and then udev started fast again.

pernix · 2012-01-23 18:11:10

Amancio wrote:

For me, the trick with MODULES in rc.conf didn't work. What I needed to do:
1. Remove 'rtl8192se' in MODULES in rc.conf (I had added just for test).
2. Add 'blacklist rtl8192se' in /etc/modprobe.d/modprobe.conf
3. Add '/sbin/modprobe rtl8192se' in /etc/rc.local
and then udev started fast again.

I had the same problem and your solution works for me! Thanks!

ql · 2012-01-23 18:17:44

Amancio wrote:

For me, the trick with MODULES in rc.conf didn't work. What I needed to do:
1. Remove 'rtl8192se' in MODULES in rc.conf (I had added just for test).
2. Add 'blacklist rtl8192se' in /etc/modprobe.d/modprobe.conf
3. Add '/sbin/modprobe rtl8192se' in /etc/rc.local
and then udev started fast again.

Thanks Amancio. This works for me with the ipw2100 driver.

S

adr3nal1n · 2012-01-23 20:22:39

ql wrote:

Amancio wrote:
For me, the trick with MODULES in rc.conf didn't work. What I needed to do:
1. Remove 'rtl8192se' in MODULES in rc.conf (I had added just for test).
2. Add 'blacklist rtl8192se' in /etc/modprobe.d/modprobe.conf
3. Add '/sbin/modprobe rtl8192se' in /etc/rc.local
and then udev started fast again.
Thanks Amancio. This works for me with the ipw2100 driver.
S

Thank you, I have used the same to get the ipw2200 driver working too.

digitalone · 2012-01-23 20:51:19

Gusar wrote:

There's still the issue of why you get "FAIL" for module loading. Check this thread, seems relevant for that: https://bbs.archlinux.org/viewtopic.php?pid=1045939

I have cpufrep_performance in modules, so it was not the problem...

Amancio wrote:

For me, the trick with MODULES in rc.conf didn't work. What I needed to do:
1. Remove 'rtl8192se' in MODULES in rc.conf (I had added just for test).
2. Add 'blacklist rtl8192se' in /etc/modprobe.d/modprobe.conf
3. Add '/sbin/modprobe rtl8192se' in /etc/rc.local
and then udev started fast again.

Did that solve to you the problem of "loading user-specified modules"?

Last edited by digitalone (2012-01-23 20:51:30)

Gusar · 2012-01-23 20:58:17

digitalone wrote:

I have cpufrep_performance in modules, so it was not the problem...

Actually, as I just replied in that thread, this is exactly what the problem is!

Oxyd00m · 2012-01-23 21:20:59

Hi.
My problem is about udev 178-1 with 3.2.1-2 kernel.

:: Waiting for UDev uevents to be processed [BUSY] (for 30 seconds)

udevd[142]: seq 1072 '/devices/pci0000:00/0000:00:1c.1/0000:02:00.0' killed

udevd[142]: worker [155] terminated by signal 9 (Killed)

This is my dmesg, and this is lspci -v
I've also put in MODULES section of rc.conf 'brcmsmac', but nothing change.
How do I fix it?

Last edited by Oxyd00m (2012-01-23 21:22:41)

Arch Linux

#26 2012-01-22 04:21:54

Re: udev hangs for 30s after upgrade

#27 2012-01-22 06:32:39

Re: udev hangs for 30s after upgrade

#28 2012-01-22 07:26:12

Re: udev hangs for 30s after upgrade

#29 2012-01-22 08:49:50

Re: udev hangs for 30s after upgrade

#30 2012-01-22 09:30:52

Re: udev hangs for 30s after upgrade

#31 2012-01-22 16:07:02

Re: udev hangs for 30s after upgrade

#32 2012-01-22 16:28:01

Re: udev hangs for 30s after upgrade

#33 2012-01-22 16:53:42

Re: udev hangs for 30s after upgrade

#34 2012-01-22 19:13:03

Re: udev hangs for 30s after upgrade

#35 2012-01-22 21:15:34

Re: udev hangs for 30s after upgrade

#36 2012-01-22 21:24:53

Re: udev hangs for 30s after upgrade

#37 2012-01-22 21:38:36

Re: udev hangs for 30s after upgrade

#38 2012-01-22 21:42:56

Re: udev hangs for 30s after upgrade

#39 2012-01-22 21:55:42

Re: udev hangs for 30s after upgrade

#40 2012-01-22 22:34:42

Re: udev hangs for 30s after upgrade

#41 2012-01-22 23:05:54

Re: udev hangs for 30s after upgrade

#42 2012-01-23 02:20:36

Re: udev hangs for 30s after upgrade

#43 2012-01-23 07:44:03

Re: udev hangs for 30s after upgrade

#44 2012-01-23 13:41:09

Re: udev hangs for 30s after upgrade

#45 2012-01-23 18:11:10

Re: udev hangs for 30s after upgrade

#46 2012-01-23 18:17:44

Re: udev hangs for 30s after upgrade

#47 2012-01-23 20:22:39

Re: udev hangs for 30s after upgrade

#48 2012-01-23 20:51:19

Re: udev hangs for 30s after upgrade

#49 2012-01-23 20:58:17

Re: udev hangs for 30s after upgrade

#50 2012-01-23 21:20:59

Re: udev hangs for 30s after upgrade

Board footer