Bug 272916

Summary: kdeinit uses max CPU after detaching auto usb networking
Product: [Unmaintained] Network Management Reporter: Lars Ivar Igesund <larsivar>
Component: KDED ModuleAssignee: Will Stephenson <wstephenson>
Status: RESOLVED DUPLICATE    
Severity: normal CC: lamarque
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Lars Ivar Igesund 2011-05-10 10:01:47 UTC
Version:           unspecified (using KDE 4.6.2) 
OS:                Linux

I recently started to use my Android phone as a tethering device to get network access for my laptop.

Connecting works flawlessly (a network-manager feature I believe), however disconnecting it does not, at least not most of the times.

What happens is that the system tray icon shows a "stop" sign (red circle with a line over it), and kdeinit runs wild. Looking at it in top, it uses as much CPU as it can (in my case a full core). Here it appears to not be very responding to anything. Reconnecting does not help.

If I kill kdeinit, it restarts and I can then connect fine again. However, this causes enough of other annoying problems, with mail certificates and whatnot, so I end restarting the computer. As I have to disconnect my phone at least a couple of times per day, this becomes more annoying.

I assume that it may be possible that the interaction between network-manager and the kde applet for it could be to blame here, but I don't think kdeinit should behave that like in any case.

Reproducible: Always

Steps to Reproduce:
Disconnect an usb0 network interface (typically a phone used for tethering).

Actual Results:  
The system tray networking applet goes to some failure state, and kdeinit goes into an neverending loop, using all available cpu.

Expected Results:  
The networking applet should have noted that it was no longer disconnected, but otherwise look normal. kdeinit should not run crazy.
Comment 1 Lamarque V. Souza 2011-05-10 20:04:33 UTC

*** This bug has been marked as a duplicate of bug 272527 ***