udev hangs for 30s after upgrade

jgreen1tc · 2012-02-17 20:06:37

This issue returned for me after this morning's update. The previous solution was to add my wireless driver to the MODULES section of /etc/rc.conf. The following resolved the issue this time:

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.

Last edited by jgreen1tc (2012-02-17 20:07:30)

sportscliche · 2012-02-20 06:45:28

Amanico's workaround did the trick for me too with an old IBM Thinkpad T42. I had to substitute ipw2100 for rtl8192se; check your wireless driver with 'lspci -v' to make sure.

stevepa · 2012-02-24 05:30:42

I have a delay also, but my problem appears to be related to hard disks, not wireless. Here is my dmesg listing from before the delay to after it. You can see the 30 sec delay. This started happening after a recent kernel upgrade. To my knowledge, the system works right, it just suffers from the delay and errors.

http://paste.pocoo.org/show/555925/

I would appreciate any tips. Thanks. Steve.

Theoden · 2012-03-03 18:43:04

This worked for me as well with the ipw2200 driver. And to make my laptop automatically bring up my network, I added the line:

netcfg wireless

to my /etc/rc.local file right after the modprobe line. 'wireless' is the name of my netcfg profile in /etc/network.d/ .

--Theoden

drrossum · 2012-03-14 19:28:22

If you use the net-profiles (netcfg) daemon, an alternative to rc.local is to add the following line to /etc/network.d/interfaces/eth1:

PRE_UP="modprobe ipw2200"

Last edited by drrossum (2012-03-14 19:46:22)

Ozymandias_117 · 2012-03-15 07:13:01

I just thought I'd throw out there... I have two arch installs on my system, I have this problem on the 64-bit version but not on the 32-bit version (Udev 181-4 on both). Just wondering if everyone else who is having the problem is also on 64-bit?

Gusar · 2012-03-15 10:45:36

The problem is in the drivers. And it'll be the same driver regardless of bit-ness. There is for sure another reason why you're not seeing it on the 32bit install.

Radioactiveman · 2012-03-15 12:36:11

Should be fixed with udev 181-5:
http://projects.archlinux.org/svntogit/ … a1d53ca264

drrossum · 2012-03-17 04:16:42

Yes, for me udev works again, with ipw2200!

Max David · 2012-04-01 21:44:06

I don't understand why the solution seems to work for everyone but me. Blacklisting the wireless module and putting the modprobe line into rc.local makes it hang for a minute. And no matter what I do, the wireless still won't work. Even when I've booted, if I try to rmmod and then modprobe my wireless module, it still takes a whole minute:

[max@Max-ThinkPad ~]$ sudo rmmod rtl8192ce
[max@Max-ThinkPad ~]$ time sudo modprobe rtl8192ce

real    1m0.258s
user    0m0.000s
sys     0m0.017s

and dmesg gives me:

[ 1237.529119] rtl8192ce 0000:08:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 1237.529137] rtl8192ce 0000:08:00.0: setting latency timer to 64
[ 1297.690174] rtl8192ce:rtl92c_init_sw_vars():<0-0> Failed to request firmware!
[ 1297.690178] rtlwifi:rtl_pci_probe():<0-0> Can't init_sw_vars.
[ 1297.690215] rtl8192ce 0000:08:00.0: PCI INT A disabled

And the wireless still doesn't show up in ifconfig.

During boot, it also seemed to hang for a minute when it was starting the SSH server, but I realized that it had nothing to do with SSH; it was just hanging because there is a delay, and then a hang, when it loads the module for the Ethernet. Blacklisting my Ethernet module in modprobe.d and adding it to rc.local just moved the delay to later in the boot process. Once I've booted, I can rmmod and modprobe the Ethernet module quickly, but then there's a one minute delay before it actually is recognized, and ifconfig will respond:

[max@Max-ThinkPad ~]$ sudo rmmod r8169
[max@Max-ThinkPad ~]$ time sudo modprobe r8169; time ifconfig

real    0m0.023s
user    0m0.003s
sys     0m0.003s
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500  metric 1
        ether f0:de:f1:90:b3:e7  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 44  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436  metric 1
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 871  bytes 78846 (76.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 871  bytes 78846 (76.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


real    1m0.931s
user    0m0.000s
sys     0m0.000s

And dmesg gives me:

[  901.846520] r8169 0000:02:00.0: PCI INT A disabled
[  920.316014] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[  920.316045] r8169 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[  920.316134] r8169 0000:02:00.0: setting latency timer to 64
[  920.316346] r8169 0000:02:00.0: irq 44 for MSI/MSI-X
[  920.316843] r8169 0000:02:00.0: eth0: RTL8168e/8111e at 0xffffc90000670000, f0:de:f1:90:b3:e7, XID 0c200000 IRQ 44
[  920.316847] r8169 0000:02:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[  981.148357] r8169 0000:02:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168e-2.fw (-2)
[  981.172338] r8169 0000:02:00.0: eth0: link down
[  981.172387] r8169 0000:02:00.0: eth0: link down
[  981.172672] ADDRCONF(NETDEV_UP): eth0: link is not ready
[  982.862504] r8169 0000:02:00.0: eth0: link up
[  982.862822] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

My network adapters are both Realtek:

[max@Max-ThinkPad ~]$ lspci | grep Realtek
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
08:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)

haidut · 2012-04-24 07:24:05

Hi!

After updating the whole system I cannot boot with the regular image. It's just stuck at "Waiting for UDev uevents to be processed" and waiting for 15-20 min does not result in any changes.

Fallback works although it gave me an error on mei. I blacklisted mei and the warning is gone for Fallback but the regular image still refuses to boot. I can find what drivers are installed by looking at /lib/modules/ but I am not sure how to check what modules are loaded by udev in my regular linux image. Could you please help me investigate what I need to blacklist?

Thanks, your help is much appreciated!

Trilby · 2012-04-24 10:43:22

Haidut, yours sounds like an unrelated problem for at least two reasons: one, yours hangs indefinitely, not for 30 seconds, and two, this issue has (allegedly) been resolved with an update of udev.

There are other threads for long or indefinite hangs of udev. The first step would be to rebuild your initramfs as that sounds like it may be the problem.

haidut · 2012-04-24 14:57:01

Hey Trilby,

Sorry, didn't mean to pollute the thread.

I just thought that since the difference between the regular and the fallback image is the autodetect option for mkinitcpio this can be solved via blacklisting. Will look for other threads on this.

Trilby · 2012-04-24 15:22:38

There is no harm in posting here - I recommended your own thread so that your question may get the attention it needs. The problem underlying this thread has been, AFAIK, solved.

Your problem is likely something very different. It could be from a problem in building ramfs as this was likely rebuilt with the upgrade. If that is not the issue, it could be something related to the driver.

haidut · 2012-04-24 15:56:33

Hi,

In my case this was resolved by blacklisting mei, iwlwifi and shpchp. No idea if this is related to this thread or not but thought I would share since the fix is very similar.

Thanks, this thread was really helpful!

murphaph · 2012-10-19 15:59:10

Hi all,
I have an indefinite hang on "waiting for udev....blah blah" problem and I know what's "causing" the problem but not how to fix. I have a Thinkpad T420 with VT-d from Intel (virtualisation technology). When I switch it on in the BIOS I get random indefinite hangs (usually have to attempt to boot ca. 5 times before it "catches"-I understand udev diesn't run processes in the same order each time, so this probably explains why it works sometimes and not others).

When it is off, the system boots without fail. The problem is, I want to enable it to run 64 Bit Windows 7 as a guest in Virtualbox and vt-d (or the AMD equivalent) is a prerequisite. I need this for work so any help would be gratefully appreciated. I've obviously googled the "waiting for..." + vt-d and nothing comes back unfortunately.

Thanks!

Arch Linux

#101 2012-02-17 20:06:37

Re: udev hangs for 30s after upgrade

#102 2012-02-20 06:45:28

Re: udev hangs for 30s after upgrade

#103 2012-02-24 05:30:42

Re: udev hangs for 30s after upgrade

#104 2012-03-03 18:43:04

Re: udev hangs for 30s after upgrade

#105 2012-03-14 19:28:22

Re: udev hangs for 30s after upgrade

#106 2012-03-15 07:13:01

Re: udev hangs for 30s after upgrade

#107 2012-03-15 10:45:36

Re: udev hangs for 30s after upgrade

#108 2012-03-15 12:36:11

Re: udev hangs for 30s after upgrade

#109 2012-03-17 04:16:42

Re: udev hangs for 30s after upgrade

#110 2012-04-01 21:44:06

Re: udev hangs for 30s after upgrade

#111 2012-04-24 07:24:05

Re: udev hangs for 30s after upgrade

#112 2012-04-24 10:43:22

Re: udev hangs for 30s after upgrade

#113 2012-04-24 14:57:01

Re: udev hangs for 30s after upgrade

#114 2012-04-24 15:22:38

Re: udev hangs for 30s after upgrade

#115 2012-04-24 15:56:33

Re: udev hangs for 30s after upgrade

#116 2012-10-19 15:59:10

Re: udev hangs for 30s after upgrade

Board footer