Red Hat Bugzilla – Bug 638640
REGRESSION: NetworkManager disables networking everytime i suspend to RAM and won't re-enable
Last modified: 2010-11-01 23:18:56 EDT
Description of problem:
Everytime I close my netbook and then open it back up later on my network is disabled. I right click on the NM applet and click enable network and nothing happens, it just sits there, I have to run service NetworkManager restart to get my networking back.
THIS IS A REGRESSION
I hadn't run a yum update on this box in about a month and everything was working fine, it wasn't until I updated everything that this started happening.
Version-Release number of selected component (if applicable):
Every miserable time.
Steps to Reproduce:
1. Boot up, connect to the network
2. Suspend to ram
Not disabled network
Would you please attach /var/log/messages after the netbook resumes and you click on "Enable networking"?
Created attachment 451393 [details]
/var/log/messages after resume
I closed the netbook at 8:56:10 and resumed it at 8:56:28 and clicked enable networking after I had typed my password and such. I had looked here before but there didn't seem to be any useful messages.
Hmm, it looks NM didn't get wake up. The log should contain something like this:
Oct 4 15:25:55 gromit NetworkManager: <info> wake requested (sleeping: yes enabled: yes)
Oct 4 15:25:55 gromit NetworkManager: <info> waking up and re-enabling...
There was a fix specifically for that:
But it seems that the signal is either not issued by upower or NM doesn't catch it. Will debug further.
To wake NM manually run as root:
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.wake
You can add --print-reply to /usr/lib64/pm-utils/sleep.d/55NetworkManager as a workaround:
One more question; is "upowerd" running?
*** Bug 636400 has been marked as a duplicate of this bug. ***
That's probably caused by the fact PowerDevil (KDE power manager) uses HAL as its backend and not UPower. Thus Sleeping/Resuming signals are not issued. See https://bugzilla.redhat.com/show_bug.cgi?id=632910#c7
Could you confirm that suspend/resume works fine under Gnome and only KDE causes the issue?
You can also try to suspend with:
dbus-send --system --print-reply --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Suspend
which should work as it emits both Sleeping and Resuming signals.
From my Lenovo T60 with F14Beta :
- I'm using KDE desktop
- upowerd is running:
# ps -efw | fgrep upow
root 1427 1 0 00:04 ? 00:00:01 /usr/libexec/upowerd
- it seems that NetworkManager rarely receives (or logs?) those wakeup events:
# head /var/log/messages
Oct 4 12:33:02 l3f1199 rsyslogd: [origin software="rsyslogd" swVersion="4.6.3" x-pid="1061" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
# fgrep -e "wake requested" -e "waking up" /var/log/messages
Oct 5 09:45:02 l3f1199 NetworkManager: <info> wake requested (sleeping: yes enabled: yes)
Oct 5 09:45:02 l3f1199 NetworkManager: <info> waking up and re-enabling...
Oct 5 10:00:29 l3f1199 NetworkManager: <info> wake requested (sleeping: yes enabled: yes)
Oct 5 10:00:29 l3f1199 NetworkManager: <info> waking up and re-enabling...
Thu Oct 7 14:26:43 EEST 2010
The occurrence of the problem is rare now, maybe once a week.
I don't use KDE, this is Gnome. And upower isn't running.
So it looks like one of two things happens, either NetworkManager fails to wake up, and that handy dbus command definitely wakes it up, or NetworkManager doesn't seem to go to sleep, but still doesn't work when my box comes back up and then it has to be restarted. The second case happens maybe 20% of the time, I open the box back up and NetworkManager seems to already be connected, but it really isn't, I can't connect to things and such, so I have to do a service NetworkManager restart.
Okay, it would be useful to have messages log for the both cases to analyze them separately.
It looks like the sleep/wake requests are not always delivered to NM.
> I don't use KDE, this is Gnome. And upower isn't running.
upowerd is D-Bus activated deamon. So it should be started when g-p-m calls Suspend D-Bus method of org.freedesktop.UPower service.
First of all check that you have latest upower and gnome-power-manager packages.
I think there were some issues with suspend in older upower.
Second, log D-Bus signals during suspend/resume:
dbus-monitor --system > dbus.log
There should be UPower's Sleeping and Resuming signals.
If suspend is done by other means that doesn't involve UPower, Nm should be poked by calling it's sleep and wake methods. This is done e.g. by pm-util hooks in 55NetworkManager as mentioned in comment #3. Here adding --print-reply could prevent loosing the D-Bus messages.
In my case, sometimes when resuming, the wireless network does not work.
Disabling and re-enabling it in the NM applet does nothing.
# service NetworkManager restart
F13 i386, Netbook [Asus 1005HA].
I am Using KDE.
NetworkManager.i686 1:0.8.1-6.git20100831.fc13 @updates
NetworkManager-glib.i686 1:0.8.1-6.git20100831.fc13 @updates
knetworkmanager.i686 1:0.9-0.20.20100603.fc13 @updates
knetworkmanager-libs.i686 1:0.9-0.20.20100603.fc13 @updates
My netbook only suspends on battey power.
Linux xxxx.xx 220.127.116.11-56.fc13.i686 #1 SMP Wed Sep 15 03:33:58 UTC 2010 i686 i686 i386 GNU/Linux
Most of the time it does not occur. (at least with a single suspend event).
This bug is against F12.
And I don't have upower installed at all on this machine either btw.
Created attachment 453195 [details]
dbus-monitor --profile --system output from around suspend/resume
From my F14 machine when NM failed to wake up after resume:
log start: 1286909001: Tue Oct 12 21:43:21 2010
suspend: 1286909255: Tue Oct 12 21:47:35 2010
resume: 1286969460: Wed Oct 13 14:31:00 2010
I'm going to try the --print-reply change to the pm-utils script.
I'll update NM to work around the pm-utils problem here:
NetworkManager-0.8.1-9.git20100831.fc14 has been submitted as an update for Fedora 14.
Updates for f12 & f13 here, let me know how they work too:
Tested the F12 version, it fixes the problem. Thanks.
NetworkManager-0.8.1-9.git20100831.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update NetworkManager'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-9.git20100831.fc14
NetworkManager-0.8.1-9.git20100831.fc12 has been submitted as an update for Fedora 12.
(In reply to comment #17)
> Tested the F12 version, it fixes the problem. Thanks.
Can you karma bump https://admin.fedoraproject.org/updates/NetworkManager-0.8.1-9.git20100831.fc12 for me then? Thanks!
*** Bug 610299 has been marked as a duplicate of this bug. ***
*** Bug 635055 has been marked as a duplicate of this bug. ***
*** Bug 633874 has been marked as a duplicate of this bug. ***
NetworkManager-0.8.1-9.git20100831.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-0.8.1-9.git20100831.fc13 has been submitted as an update for Fedora 13.
(In reply to comment #0)
> Description of problem:
> Everytime I close my netbook and then open it back up later on my network is
> disabled. I right click on the NM applet and click enable network and nothing
> happens, it just sits there, I have to run service NetworkManager restart to
> get my networking back.
Is it part of the regression, that if switching places, to still see the old networks (which are definetely not available anymore)?
This happened sometimes on my system, F13 (e.g., for hidden networks).
NetworkManager-0.8.1-9.git20100831.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
NetworkManager-0.8.1-9.git20100831.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 644990 has been marked as a duplicate of this bug. ***