NetworkManager causes high CPU-usage after suspend

[Stephan Sailer]

After upgrading to Gutsy, NetworkManager starts a second process after wakeup from suspend-to-RAM. One process causes up to 100% CPU-usage and is only killable with "kill -9" - HUP doesn't work. The other process of NetworkManager seems to work perfectly.
My System is a "IBM Thinkpad T41" with an Intel Gigabit LAN-Adaptor ("e1000") and an Intel IPW2915ABG WLAN-Card ("ipw2200"). I'm running Linux-kernel 2.6.22-14-generic without any patches on the network-drivers.

[mrAshley (launchpad-mrashley)]

I have the same symptoms. I can kill -9 NetworkManager and restart it and everything seems to be fine at that point.

lspci says my wireless is this:
Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)
and my wire (which I don't use) is this:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

[chiefaua (chiefaua)]

I have the same problems.

I attached a gdb and found out, that NetworkManager continously receives SIGSEGV:

(gdb) stepi
0x0806e930 in ?? ()
(gdb) stepi
0x0806e931 in ?? ()
(gdb) stepi
0x0806e933 in ?? ()
(gdb) stepi
0x0806e934 in ?? ()
(gdb) stepi
0x0806e937 in ?? ()
(gdb) stepi
0x0806e93c in ?? ()
(gdb) stepi
0x0806e93f in ?? ()
(gdb) stepi
0x0806e941 in ?? ()
(gdb) stepi
0x0806e943 in ?? ()
(gdb) stepi
0x0806e946 in ?? ()
(gdb) stepi
0x0806e947 in ?? ()
(gdb) stepi
0x0806e948 in ?? ()
(gdb) stepi
<signal handler called>
(gdb) stepi
<signal handler called>
(gdb) stepi
<signal handler called>
(gdb) stepi
0x98e80c4d in ?? ()
(gdb) stepi

Program received signal SIGSEGV, Segmentation fault.
0x98e80c4d in ?? ()
(gdb) stepi
0x0806e930 in ?? ()
(gdb) stepi
0x0806e931 in ?? ()
(gdb) stepi
0x0806e933 in ?? ()
(gdb) stepi
0x0806e934 in ?? ()
(gdb) stepi
0x0806e937 in ?? ()
(gdb) stepi
0x0806e93c in ?? ()
(gdb) stepi
0x0806e93f in ?? ()
(gdb) stepi
0x0806e941 in ?? ()
(gdb) stepi
0x0806e943 in ?? ()
(gdb) stepi
0x0806e946 in ?? ()
(gdb) stepi
0x0806e947 in ?? ()
(gdb) stepi
0x0806e948 in ?? ()
(gdb) stepi
<signal handler called>
(gdb) stepi
<signal handler called>
(gdb) stepi
<signal handler called>
(gdb) stepi
0x98e80c4d in ?? ()
(gdb) stepi

Program received signal SIGSEGV, Segmentation fault.
0x98e80c4d in ?? ()

The backtrace is the following:
(gdb) bt
#0 0x98e80c4d in ?? ()
#1 0x0806b49d in ?? ()
#2 0xb7edf490 in g_child_watch_funcs () from /usr/lib/libglib-2.0.so.0
#3 0x0809b140 in ?? ()
#4 0xbfc0d5e8 in ?? ()
#5 0xb7e75033 in g_thread_self () from /usr/lib/libglib-2.0.so.0
#6 0xb7e528d6 in ?? () from /usr/lib/libglib-2.0.so.0
#7 0x0809b140 in ?? ()
#8 0xb7dbe8ac in __pthread_mutex_unlock_usercnt () from /lib/tls/i686/cmov/libpthread.so.0
#9 0xb7e5211c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#10 0xb7e5555f in ?? () from /usr/lib/libglib-2.0.so.0
#11 0x08097398 in ?? ()
#12 0x00000064 in ?? ()
#13 0x0809f840 in ?? ()
#14 0x00000005 in ?? ()
#15 0x00000005 in ?? ()
#16 0xb7dbe8ac in __pthread_mutex_unlock_usercnt () from /lib/tls/i686/cmov/libpthread.so.0
#17 0xb7e55909 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#18 0x0806a8f1 in main ()

lspci:
...
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:04.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)
...

[Andreas Schildbach (schildbach)]

I've got the same problem, on a Dell Latitude X1.

01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)
        Subsystem: Dell Unknown device 01a3
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at dfdf0000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data
        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable-
        Capabilities: [d0] Express Endpoint IRQ 0

02:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)
        Subsystem: Intel Corporation Unknown device 2721
        Flags: bus master, medium devsel, latency 64, IRQ 18
        Memory at dfcff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [dc] Power Management version 2

Probably as a side effect of this, there are no routes after suspend (no network) - see bug #155432.

[Andreas Schildbach (schildbach)]

Setting this to confirmed because one of the duplicates was already confirmed, but this report contains useful information.

[Andreas Schildbach (schildbach)]

This seems to have been fixed in 0.6.5-0ubuntu16.7.10.0, which is available in gutsy-proposed. Suspend worked seamlessly and the wireless network stayed alive.

[Haggai Eran (haggai-eran)]

Hi,

I suffered from this bug before too. After upgrading to 0.6.5-0ubuntu16.7.10.0 networkmanger uses 100% of the cpu all the time, and not just after suspend. top's output says about 80% of the cpu is used by the system.

The network connection however is working fine.

Thanks,
Haggai

[Dima Ryazanov (dima-gmail)]

I'm having a similar problem. In my case, though, there's only one process - it uses 100% of the CPU, and doesn't actually connect.
Just before suspend, I unplugged the ethernet cable, and NetworkManager started connecting to a wireless network - but probably didn't finish. After I resumed the laptop, it was still in the same state (at least, according to nm-applet).

The backtrace:

#0 0xb7cefd80 in __pthread_disable_asynccancel () from /lib/tls/i686/cmov/libpthread.so.0
#1 0xb7cf0a00 in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7da5962 in g_usleep () from /usr/lib/libglib-2.0.so.0
#3 0x0806cbaa in ?? ()
#4 0x0000c350 in ?? ()
#5 0xbf82d42c in ?? ()
#6 0xbf82d408 in ?? ()
#7 0xb7d821ea in g_source_attach () from /usr/lib/libglib-2.0.so.0
#8 0x08055c85 in nm_device_activation_cancel ()
#9 0x08055e6a in nm_device_deactivate_quickly ()
#10 0x08055f01 in nm_device_deactivate ()
#11 0x080577d6 in nm_device_stop ()
#12 0x080694f2 in nm_remove_device ()
#13 0x08069623 in ?? ()
#14 0x08097330 in ?? ()
....

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

 Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

[Leon van der Ree (lvanderree)]

I haven't experienced any problems anymore in 8.10

[Haggai Eran (haggai-eran)]

I also haven't seen this bug in 8.04 or 8.10.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Thank you. This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status . Thank you again for taking the time to report this bug and helping to make Ubuntu better. Feel free to submit any future bugs you may find.