Description of problem: After waking up from a hibernation mode, all network devices are turned off (as shown by gnome networkmanager, or by ifconfig, which only lists "lo"). With the previous (2.6.33.6-147) kernel this used to work fine. Version-Release number of selected component (if applicable): Linux inferno 2.6.33.8-149.fc13.x86_64 #1 SMP Tue Aug 17 22:53:15 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Suspend the laptop. Wake it up again. Network devices are disabled. Additional info: Wireless device is an Intel (AFAIK iwlagn + cfg80211 kernel modules). The "dmesg" after waking up did not show anything suspicious.
Ok, this time it worked, so it's not 100% reproducible, but it seems flaky nonetheless. dmesg shows the following (for a working wake up): [...] PM: restore of devices complete after 3843.092 msecs PM: Image restored successfully. Restarting tasks ... done. PM: Basic memory bitmaps freed usb 2-5: reset high speed USB device using ehci_hcd and address 2 atl1c 0000:01:00.0: irq 30 for MSI/MSI-X ADDRCONF(NETDEV_UP): eth0: link is not ready ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: direct probe to AP 00:1c:df:45:c2:61 (try 1) wlan0: direct probe responded [... further authentication of wlan0 ...] Maybe the "link is not ready" messages bear some significance (even though this time they do work)?
When waking up doesn't wake the network devices, they don't even show up in dmesg, so it seems like the kernel doesn't even discover they're there. Unloading and reloading the cfg80211 module also didn't do anything. PM: restore of devices complete after 3851.002 msecs PM: Image restored successfully. Restarting tasks ... done. PM: Basic memory bitmaps freed usb 2-5: reset high speed USB device using ehci_hcd and address 2 and that's it.
kernel-2.6.34.6-47 has been submitted as an update for Fedora 13. Please try that when it becomes available.
I confirm this bug on my EeePC with the same kernel. I noticed it after opgrade from previous kernel version.
Good reason to enable updates-testing :-) I've resumed my laptop with kernel-2.6.34.6-47 several times now, without any problems. If this nothing bad happens, I'll close the bug in a day or so.
Too bad, just woke up the laptop and no network devices came up... so the problem still persists with Linux inferno 2.6.34.6-47.fc13.x86_64 #1 SMP Fri Aug 27 08:56:01 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
I have 2.6.23.6-47.fc13.x86_64, and the problem still exists. Sometimes the devices survice suspend, but typically need reboot to recover. Wireless driver is iwlagn, hardware is Thinkpad X200. Any workarounds?
I have similar issues, I have a toshiba laptop and have noticed this. I think it may be a NetworkManager issue more than kernel, simply because I get around it by doing 'sudo service NetworkManager restart' which then grabs an IP... I'd like to know the issue as well. 02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)
I still have this problem, and tried the suggested workaround: 'service NetworkManager restart'. It works for me. Thanks.
I can confirm that this problem actually seems to be in NetworkManager. "service NetworkManager restart" fixes the problem.
I opened a bug against NetworkManager, bug #632115
same problem. Intermittent ~30% resumes from S3 (suspend). 32 bit kernel (which manages my 8gB DRAM very nicely. Standard pre-build RPM supports 64gB DRAM. Why run a 64 bit kernel except for 64 bit development or large RDBMS server?). --- [bvn@office ~]$ sudo ifconfig eth0 up [bvn@office ~]$ sudo ifconfig eth0 Link encap:Ethernet HWaddr 00:24:8C:BF:D5:D0 inet6 addr: fe80::224:8cff:febf:d5d0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:192608992 errors:0 dropped:0 overruns:0 frame:0 TX packets:192509533 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1620489346 (1.5 GiB) TX bytes:2604356400 (2.4 GiB) Interrupt:27 Base address:0x8000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1889 errors:0 dropped:0 overruns:0 frame:0 TX packets:1889 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1938051 (1.8 MiB) TX bytes:1938051 (1.8 MiB) [bvn@office ~]$ sudo service network restart Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: Error: Connection activation failed: Device not managed by NetworkManager [FAILED] [bvn@office ~]$ uname -r 2.6.34.6-47.fc13.i686.PAE [bvn@office ~]$ rpm -qa | grep network system-config-network-1.6.1-1.fc13.noarch system-config-network-tui-1.6.1-1.fc13.noarch [bvn@office ~]$ rpm -qa | grep Network NetworkManager-0.8.1-6.git20100831.fc13.i686 NetworkManager-openconnect-0.8.1-1.fc13.i686 NetworkManager-gnome-0.8.1-6.git20100831.fc13.i686 NetworkManager-openvpn-0.8.1-1.fc13.i686 NetworkManager-pptp-0.8.1-1.fc13.i686 NetworkManager-vpnc-0.8.1-1.fc13.i686 NetworkManager-glib-0.8.1-6.git20100831.fc13.i686 [bvn@office ~]$
you can also 'disable' then 'enable' networking via NM and it acquires an IP thereafter.
'disable' then 'enable' doesn't work for me - the box is already unchecked and won't accept a recheck. Restarting NetworkManager (as in Comment 9) does: # service NetworkManager restart
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.