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
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
is the service networkmanager running after the suspend ? ie systemctl status networkmanager.service iirc
Blocks: (none) => 7551
Blocks: (none) => 7557
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.
Hello Manuel, Just wanted to find out if you need any other debug info... Thanks, Vladimir
nop I don't know
CC: (none) => mageia, mageia
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 :(
closing then, feel free to reopen
Status: NEW => RESOLVEDResolution: (none) => OLD
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.
(In reply to comment #8) n/a here
CC: (none) => ftg