NetworkManager hangs with 100% cpu

I have the same symptoms in Feisty. It does not happen all the time, but it is quite frequent. What information would help resolve this?

It happens to me also after i kill and start again dhcdbd

Hi, Could you please test with the debugging package installed as described here: https://wiki.ubuntu.com/DebuggingProgramCrash ?

It would be best if you could test it in Gutsy, as it's more likely to be resolved there. Thanks!

Can you please test this with latest gutsy network-manager (0.6.5-0ubuntu14).

Thanks,

 - Alexander

Not before gutsy is released I'm afraid, this is a production machine.

Sorry,
 - Nikolaus

I am running Gutsy and with network-manager (0.6.5-0ubuntu14) I see the same problem at startup. I did the upgrade from Feisty and that is when the issue was first seen. I do not have any wireless interface on my system only a wired connection.

I think this bug is related to this one: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/123332

Albert, does the Dispatcher consume your cpu cycles (like in the bug you pointed to)?

Alexander,

Actually my problem is with NetworkManagerDispatcher but it could be that we are referring to the same issue since it also happens at startup. Yes, It does consume my cpu cycles like the bug I pointed to and the high cpu load disappears after 3 to 5 minutes.

I am using htop instead of top to see a tree of what NetworkManagerDispatcher is doing. I only noticed that its continues to call wpa_supplicant and other files in /etc/network/if-*

It looks like the kind of cpu usage one gets when doing an infinite loop. Then all of the sudden it breaks/times out and cpu usage drops to normal. I guess this is happening when its detecting the available networks.

we inserted a timeout between activation attempts in order to not consume too much cycles for the time the dhcbdb server isn't yet started. So I assume its fixed in latest gutsy (0.6.5-0ubuntu15).

If you still see it in that version, feel free to reopen.

Still happens in current Gutsy after resuming from suspend. Had this several times. The only solution is to kill NetworkManager with -9 parameter and restart it through "sudo /etc/dbus-1/event.d/25NetworkManager restart"
Seems to happen if you suspend shortly after resume. After resume the nm-applet icon still shows a connection and then disables it so a computer with a red triangle is shown. If you suspend in this stage I get the 100% cpu problem after resume.

Oct 13 01:26:14 uber NetworkManager: <info> Activation (eth1) Stage 3 of 5 (IP Configure Start) started...
Oct 13 01:26:15 uber gnome-power-manager: (user) Suspending computer because the power button has been pressed
Oct 13 01:26:15 uber NetworkManager: <debug> [1192231575.860382] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/net_00_01_4a_f4_96_7c').

More information in syslog file.

It always happens if NetworkManager is in Stage 3 while suspending. I need the -9 kill parameter because NetworkManager isn't responding to normal kill or restarts commands.

I can confirm I experience the same behavior as unggnu in Gutsy. Do you need any information more? I'd be pleased to provide you anything...

I see this bug since I upgraded to Gutsy, but I cannot remember seeing it before...
Does this bug exist only in some configurations ?

How can I help ?

Also seeing this on my laptop with NetworkManager 0.6.5ubuntu15

the same problem on my DELL xps m1210,kubuntu 7.10 2.6.22-14-generic (with latest gutsy network-manager (0.6.5-0ubuntu14).), the problem is solved when y do

sudo /etc/init.d/dbus restart

How can I help ? what other information you need?

I see the same problem on two different laptops when rapidly changing wireless network.
I think that this bug priority should be set to high. It's terrible especially since it worked perfectly for months!

I can confirm this on a dell d610, intel 2200bg wlan.
up to date Oct 17-07

I can confirm this on a dell d610, intel 2200bg wlan.
up to date Oct 17-07

Sorry forgot using 7.10

I can confirm Adolfo Benedetti suggestion
by restarting the dbus system the problem is solved.

Seeing this too, coming out of suspend on a Dell Inspiron 600M w/ifw2200 wireless.

I'm having this same problem on my Dell Inspiron 700m with the latest version of gutsy.

Jim and Ben, did you try if restarting the dbus system solves the problem?

sudo /etc/init.d/dbus restart

for me this solved the problem permanently.

Thanks for the info!

The only way I can fix this, is by kill the networkmanager and start it,
else it will use 100% and not connect.

On 10/18/07, marcogoni <email address hidden> wrote:
>
> Jim and Ben, did you try if restarting the dbus system solves the
> problem?
>
> sudo /etc/init.d/dbus restart
>
> for me this solved the problem permanently.
>
> Thanks for the info!
>
> --
> NetworkManager hangs with 100% cpu
> https://bugs.launchpad.net/bugs/83623
> You received this bug notification because you are a direct subscriber
> of the bug.
>

ok, maybe a bit far taken, but maybe its fixed by the package provided in
https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/145683/comments/15 as well?

I upgraded to the packages here:

https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/145683/comments/15

It's too early to tell if the suspend hang will happen (only tried it once and it didn't hang), but I did notice that the NM was much more responsive after resume. Previously it would take a minute or longer to finally get its act together and reconnect after resume, but with the new packages it was reconnecting by the time I had unlocked the computer.

Will post more as I find it.

I can confirm the 100% CPU behavior on a Dell M1210. Upgrading (downgrading?) to the packages above seem to be working - no hangs so far.

So I've come out of resume successfully about 10 times with the new packages, they definitely do the trick over the stock gutsy version for me.

ok, this appears to be fixed in the ppa package mentioned above. Lets wait a bit more for other confirmations and then update that package.

The ppa package seems to work for me too. Thanks.

I had problems similar to those described here, and those ppa packages seem to have fixed things.

Yes after I installed the ppa packages it seems to work.

On 10/20/07, Darwin Award Winner <email address hidden> wrote:
>
> I had problems similar to those described here, and those ppa packages
> seem to have fixed things.
>
> --
> NetworkManager hangs with 100% cpu
> https://bugs.launchpad.net/bugs/83623
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I had the same problem with gusty, the ppa package solved the problem.

Same problem with gutsy, the ppa package seems to have solved the problem.

Also confirming that the ppa package solved the problem for me in Gutsy. Get it into SRU :)

When does the ppa package uploaded to ubuntu-updates? It seems to work fine for everybody who have posted.

I'd also appreciate the release of the update. The old 'behaviour' of NetworkManager is really annoying.

I hate to spoil the party, but the ppa downgrade did not fix the problem for me. NetworkManager keeps my cpu busy at 80-90% all the time.
I wonder if my problem is the same as yours, as the dbus restart did not solve it for me either.

Same for me. On my Samsung X20 suspend to RAM was broken anyhow, but I was able to fix it by compiling a custom kernel. All solutions mentioned above didn't work for me. I just prevent the nm-applet to run and everything is O.K. I just select my network configuration manually.

Maybe it is a good idea for people which still has a problem with the ppa package to post more information like Networkmanager logs, lspci and a detailed description when it happens.

network-manager (0.6.5-0ubuntu17) hardy; urgency=low

  * upload 0.6.5-0ubuntu17 to hardy

network-manager (0.6.5-0ubuntu16.7.10.0) gutsy-proposed; urgency=low

  Release changes from test package previously known as 0.6.5-0ubuntu16~ppa3:
  * drop gracefull supplicant shutdown feature and its followup patches,
    because they cause crashes and a real fix would need more intrusive code
    rewrites: (LP: #145683, LP: #83623, LP: #152098, LP: #151405)
    - debian/patches/41n_graceful_supplicant_shutdown.patch,
      debian/patches/41q_retry_supplicant_cleanup_startup_if_ctrl_interface_connect_failes.patch,
      debian/patches/41v_lp141233-fix-supplicant-cleanup-crashes.patch,
      debian/patches/41w_lp145683_cancel_scan_in_supplicant_cleanup.patch: drop
        patches that belong to the "graveful supplicant feature".
    - debian/patches/41u_custom_timeout_for_some_wpa_ctrl_operations.patch: update
      interleaving patch
    - debian/patches/series: update quilt series accordingly.
  * debian/patches/24pp_svn2604_Add-HAL-based-rfkill-support.patch: use
    gint32 instead of guint32 for getting the killswitch power argument
    (LP: #138794).

 -- Alexander Sack <email address hidden> Mon, 05 Nov 2007 19:14:43 +0100

The new release woks for me on my Samsung X20. Thanks.

The new release works very well on my Thinkpad X40 :-) Thanks a lot !

The new release works fine with my Compal HEL81, the previous release had the 100% CPU problem.

The new release has been working with my Gateway M275 Tablet PC for several weeks. Thank you!

While this fixes the NetworkManager hanging with 100% cpu issue, I still am experiencing a residual effect where NetworkManager uses a high fraction of CPU after connecting to a static ip address (see https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/153816).

Anybody knows when the package 0.6.5-0ubuntu16.7.10.0 will be insert in gutsy?

Regards,
Dario

After nearly two months with the fixed version, I think I identified a case were NetworkManager still use 100% CPU and needs to be killed. Here is the step to reproduce :

 - hit the Fn+F4 key (= suspend-to-ram shortcut on my thinkpad X40)
 - while the computer is suspending (blinking 'moon' led), close the lid (= closing the lid is configured to initiate a suspend-to-ram)

 => upon resume, NetworkManager will hang with 100% cpu.

Once hanged, NetworkManager needs to be killed with 'kill -9' and could be restarted (sudo /etc/dbus-1/event.d/25NetworkManager restart), but it will hang again at each subsequent resume from suspend-to-ram.

Hope it helps.

On Thu, Jan 03, 2008 at 07:22:52AM -0000, Manuel Siggen wrote:
> After nearly two months with the fixed version, I think I identified a
> case were NetworkManager still use 100% CPU and needs to be killed. Here
> is the step to reproduce :
>
> - hit the Fn+F4 key (= suspend-to-ram shortcut on my thinkpad X40)
> - while the computer is suspending (blinking 'moon' led), close the lid (= closing the lid is configured to initiate a suspend-to-ram)
>
> => upon resume, NetworkManager will hang with 100% cpu.
>
> Once hanged, NetworkManager needs to be killed with 'kill -9' and could
> be restarted (sudo /etc/dbus-1/event.d/25NetworkManager restart), but it
> will hang again at each subsequent resume from suspend-to-ram.
>
> Hope it helps.
>

please open a new bug for this.

 - Alexander

I seem to be having this issue under Hardy. I'm NOT seeing the 100% cpu usage issue, but on resume NetworkManager hangs and cannot be killed except with -9.