Bug 7498 - NetworkManager loses control over the devices after the system has been suspended by powerdevil
Summary: NetworkManager loses control over the devices after the system has been suspe...
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 7551 7557
  Show dependency treegraph
 
Reported: 2012-09-16 22:01 CEST by Vladimir Gurevich
Modified: 2012-10-29 14:26 CET (History)
3 users (show)

See Also:
Source RPM: plasma-krunner-powerdevil-4.9.1-1.mga3
CVE:
Status comment:


Attachments

Description Vladimir Gurevich 2012-09-16 22:01:05 CEST
I have a Dell Latitude D820 laptop with both Ethernet and WiFi. Normally, both are on, though it doesn't seem to matter in this case. Both interfaces are configured to be managed by the NetworkManager.

[root@umka ~]# grep NM_CONTROLLED /etc/sysconfig/network-scripts/ifcfg*
/etc/sysconfig/network-scripts/ifcfg-eth0:NM_CONTROLLED=yes
/etc/sysconfig/network-scripts/ifcfg-eth1:NM_CONTROLLED=yes

The PowerDevil is configured such as that the system will be suspended upon laptop lid close:

[root@umka ~]# grep lidAction ~vag/.kde4/share/config/powermanagementprofilesrc
lidAction=1
lidAction=1
lidAction=1

Upon the cold boot, everything runs just fine, the interfaces are properly managed, etc.

[root@umka ~]# nmcli nm status
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN      
running         connected       enabled         enabled    enabled         disabled  
[root@umka ~]# nmcli dev status
DEVICE     TYPE              STATE        
eth0       802-3-ethernet    connected    
eth1       802-11-wireless   disconnected 
[root@umka ~]# nmcli con status
NAME                      UUID                                   DEVICES    DEFAULT  VPN   MASTER-PATH                                 
System eth0               5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03   eth0       yes      no    --       

After I close the lid, the laptop goes into the standby (suspended, sleep) state just fine and when I open the lid later, it wakes up properly too.

However, after the wakeup, the network is down. The Network Manager Applet Icon that looked like plugged-in RJ-45 connector, now looks as a big white "X" on the red background. 

The new state looks as follows:
[root@umka ~]# nmcli con status
NAME                      UUID                                   DEVICES    DEFAULT  VPN   MASTER-PATH                                 
System eth0               5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03   eth0       yes      no    --                                          
[root@umka ~]# nmcli nm status
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN      
running         asleep          enabled         enabled    enabled         disabled  
[root@umka ~]# nmcli dev status
DEVICE     TYPE              STATE        
eth0       802-3-ethernet    unmanaged    
eth1       802-11-wireless   unmanaged    
[root@umka ~]# nmcli con status
NAME                      UUID                                   DEVICES    DEFAULT  VPN   MASTER-PATH                                 

As you can see for whatever reason, NetworkManager fails to wake up (STATE="asleep")

Now, I can wake it up manually and bring the connections up:

[root@umka ~]# nmcli nm sleep false

All the connections come up as they were before the suspend.

[root@umka ~]# nmcli nm  status
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN      
running         connected       enabled         enabled    enabled         enabled   
[root@umka ~]# nmcli dev  status
DEVICE     TYPE              STATE        
eth0       802-3-ethernet    connected    
eth1       802-11-wireless   disconnected 
[root@umka ~]# nmcli con status
NAME                      UUID                                   DEVICES    DEFAULT  VPN   MASTER-PATH                                 
System eth0               5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03   eth0       yes      no    --                                          

However, another problem comes up. After that, the laptop fails to go to the suspended state upon the lid close anymore. I couldn't diagnose why.

On the other hand, suspending the laptop using systemd (systemctl suspend) works flawlessly. Not only the system goes into the standly correctly, it wakes up with the NetworkManager intact.

Therefore I suspect that this issue might be PowerDevil-specific.

Priority-wise I'll set it "Normal" for now, but it is between Normal and Major in my opinion, since the suspend-on-lid-close is crucial for laptops.

Thanks,
Vladimir
Comment 1 Vladimir Gurevich 2012-09-20 22:55:57 CEST
After a big upgrade to kernel-desktop-3.5.4-1.mga3-1-1.mga3 and all the subsequent packages I still see the problem. 

Given how important the standby(suspend) is for laptops, I'll upgrade the severity to major.

Thanks,
Vladimir

Severity: normal => major

Comment 2 Manuel Hiebel 2012-09-23 20:59:04 CEST
is the service networkmanager running after the suspend ?

ie systemctl status networkmanager.service iirc

Blocks: (none) => 7551

Manuel Hiebel 2012-09-23 21:20:34 CEST

Blocks: (none) => 7557

Comment 3 Vladimir Gurevich 2012-09-23 23:06:11 CEST
Here is the output after the suspend:

[root@umka vag]# systemctl status networkmanager.service
NetworkManager.service - Network Manager
          Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
          Active: active (running) since Sat, 22 Sep 2012 23:55:10 -0700; 14h ago
        Main PID: 1177 (NetworkManager)
          CGroup: name=systemd:/system/NetworkManager.service
                  รข 1177 /usr/sbin/NetworkManager --no-daemon

Sep 23 14:01:46 umka.den.paulidav.org NetworkManager[1177]: <info> (eth0): device state change: dis...7]
Sep 23 14:01:46 umka.den.paulidav.org NetworkManager[1177]: <info> (eth0): cleaning up...
Sep 23 14:01:46 umka.den.paulidav.org NetworkManager[1177]: <info> (eth0): taking down device.
Sep 23 14:01:46 umka.den.paulidav.org NetworkManager[1177]: <info> (eth1): now unmanaged
Sep 23 14:01:46 umka.den.paulidav.org NetworkManager[1177]: <info> (eth1): device state change: act...7]
Sep 23 14:01:47 umka.den.paulidav.org NetworkManager[1177]: <info> (eth1): deactivating device (rea...7]
Sep 23 14:01:47 umka.den.paulidav.org NetworkManager[1177]: <info> (eth1): canceled DHCP transactio...39
Sep 23 14:01:47 umka.den.paulidav.org NetworkManager[1177]: <info> ((null)): removing resolv.conf f...nf
Sep 23 14:01:47 umka.den.paulidav.org NetworkManager[1177]: <info> (eth1): cleaning up...
Sep 23 14:01:47 umka.den.paulidav.org NetworkManager[1177]: <info> (eth1): taking down device.

While it appears to be running it is in the sleep state, as I mentioned in the bug description:

[root@umka ~]# nmcli nm status
RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN 
running         asleep          enabled         enabled    enabled        
disabled  

And, yes, restarting the service (systemctl restart networkmanager.service) fixes the problem too.
Comment 4 Vladimir Gurevich 2012-10-06 18:49:48 CEST
Hello Manuel,

Just wanted to find out if you need any other debug info...

Thanks,
Vladimir
Comment 5 Manuel Hiebel 2012-10-07 12:28:41 CEST
nop I don't know

CC: (none) => mageia, mageia

Comment 6 Vladimir Gurevich 2012-10-16 07:01:47 CEST
Good News!

After upgrading to knetworkmanager-0.9.0.5-1.mga3 (and KDE-4.9.2 in general) the problem disappeared.

Bad News: we still don't know why :(
Comment 7 Manuel Hiebel 2012-10-27 23:24:31 CEST
closing then, feel free to reopen

Status: NEW => RESOLVED
Resolution: (none) => OLD

Comment 8 Frank Griffin 2012-10-29 13:24:07 CET
Please refer to the discussion in bug#7873 and bug#2160 and see if your problems with NM go away if you either allow GNOME (if you have it installed) to activate it or you install plasma-network-management under KDE, add it to your panel, and use it to configure your SSID.

For NM to handle wireless correctly, it needs to create SSID-specific files of its own by parsing the ifcfg files produced by drakconnect.  GNOME's nm-applet does this automatically, since it has no option to *not* use NM, but since NM isn't the default yet for other desktops, it doesn't happen automatically there.  

You'll need to install NM and let it start, and recreate your wireless interface with drakconnect specifying "Allow NM to control this interface".

Please test and post your results, as whether NM works for all the chips involved when it's properly configured will have a significant impact on how it needs to be handled for non-GNOME desktops in MGA3.
Comment 9 Frank Griffin 2012-10-29 14:26:35 CET
(In reply to comment #8)

n/a here

CC: (none) => ftg


Note You need to log in before you can comment on or make changes to this bug.