Description of problem: With a working network connection on this laptop (Dell Latitude D630), if I unplug the network cable and plug it back in, network works just fine. If I unplug cable and close lid of laptop (locking the screen), upon unlocking screen and plugging in cable, network fails, even after trying to restart NetworkManager and/or network service, etc. Interestingly, the 'reboot' command doesn't solve it. 'Shutdown -h now' and then startup solves it. Also, if I do ifdown p3p1 and service network stop first, then unplug and close lid, upon unlocking the screen network works fine. So I have to manually stop the device before I unplug cable and close lid...else I'll never get it to work until I restart the system. It appears that ifdown doesn't actually terminate the device, because I still see it as UP after doing an ifdown on the device: ifdown p3p1 ifconfig p3p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 Version-Release number of selected component (if applicable): I'm not really sure what's to blame here....NetworkManager perhaps? uname -a Linux laptop.company.com 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux rpm -qa | grep etwork NetworkManager-0.9.6.4-3.fc17.x86_64 NetworkManager-gnome-0.9.6.4-3.fc17.x86_64 NetworkManager-openvpn-0.9.3.997-1.fc17.x86_64 NetworkManager-gtk-0.9.6.4-3.fc17.x86_64 NetworkManager-vpnc-0.9.3.997-1.fc17.x86_64 system-config-network-tui-1.6.5-1.fc17.noarch glib-networking-2.32.3-1.fc17.x86_64 evolution-NetworkManager-3.4.4-2.fc17.x86_64 NetworkManager-openconnect-0.9.4.0-7.git20120612.fc17.x86_64 NetworkManager-pptp-0.9.3.997-1.fc17.x86_64 NetworkManager-glib-0.9.6.4-3.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. Unplug cable, close laptop lid 2. Open lid, unlock screen, plug in cable (in any order). 3. Test network connection. ping, etc. Actual results: Network service is not working, even after service restarts. Expected results: Network should be up once cable gets plugged back in. Instead network cannot be started and there is no connectivity. Device appears to be frozen but nonworking. Additional info: Tried renaming device as eth0 in the config file since it is an integrated NIC, but ifconfig still showed it up as device 'p3p1' even after reboot. No 70-persistent-net-rules to delete in /etc/udev/rules.d, so that was not where it was getting the device name...Wasn't sure why it insists on using that device name even when the config file says different. contents of ifcfg-p3p1: DEVICE=p3p1 #DEVICE=eth0 BOOTPROTO=dhcp NM_CONTROLLED=yes ONBOOT=yes TYPE=Ethernet NAME=p3p1 #NAME=eth0 PEERDNS=yes USERCTL=no IPV6INIT=no HWADDR=xxxxxxxxxxx DHCP_HOSTNAME=xxxxxxxxxxxx.com DNS1=xxxxxxxxxxxxx DNS2=xxxxxxxxxxxxx SEARCH=xxxxxxxxxxxx.com
First, I can't reproduce with fresh F18 install. It work OK and wired connection is correctly re-established on opening the lid. Second, naming device is task for biosdevname package. It creates the name p3p1. You cannot rename the device via DEVICE or NAME variables in ifcfg-x file, nor the ifcfg file name itself. If you really want eth0, then you should use the legacy file 70-persistent-net.rules for that. Third, please attach /var/log/messages so that we can see logs and analyze what's going on. What ethernet chip/driver do you use?: lspci
lspci output: 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c) 00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 0c) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation G86M [Quadro NVS 135M] (rev a1) 03:01.0 CardBus bridge: O2 Micro, Inc. Cardbus bridge (rev 21) 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5755M Gigabit Ethernet PCI Express (rev 02) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
Created attachment 674916 [details] messages log
You said that you can't reproduce on F18, but can you reproduce on f17 as I can? Please let me know if you need other info. Thanks
Thanks for the logs. It shows that the problem is caused by your ethernet driver, so it doesn't matter if I try F18 or F17 as I have another chip. Your Broadcom chip is handled by tg3 driver. And the driver has problems to resume from sleep: Jan 8 10:05:57 itloanerlty kernel: [689160.154041] tg3 0000:09:00.0: Refused to change power state, currently in D3 Jan 8 10:05:59 itloanerlty kernel: [689161.708546] tg3 0000:09:00.0: p3p1: No firmware running kernel version is 3.6.11-1.fc17.x86_64 Reassigning to kernel for now.
Are you still seeing this with 3.7.9 or 3.8.2 in updates-testing?
Yes, with 3.7.9: # uname -a Linux xxxxxx.xxxx.com 3.7.9-104.fc17.x86_64 #1 SMP Sun Feb 24 19:19:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux I don't use the testing repo. I would only use it if I knew it was verified to be fixed in that version first. But I haven't seen any indication that this bug has been addressed yet.
Bug still present in kernel: 3.8.8-100.fc17.x86_64 #1 SMP
Interesting note for those troubleshooting this issue: I can repro the issue by what was described above, however I can also prevent it from happening by the following procedure: 1) ifdown p3p1, Lock OS, close laptop lid. Unplug power and network. 2) Open laptop lid, unlock. Check /var/log/messages for the 'D3 message' as described above - no messages. Plug in power and network, check messages again, still nothing; ifup p3p1. It seems that plugging in the power and network BEFORE I open the laptop lid & unlock the OS causes this issue to happen more frequently, FWIW.
Are you still seeing this with the 3.9.4 kernel in updates-testing?
uname -a Linux xxxxx.xxxx.com 3.8.13-100.fc17.x86_64 #1 SMP Mon May 13 13:36:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux I don't use the updates-testing repo, as this is a production system and I don't want any kernels installed which are in "testing" mode. I did however, get this again today, on the 3.8.13 kernel (see above). So it is at least present with that kernel. Has no one been able to reproduce this problem yet? Can I give you any more information so you can reproduce it yourselves?
It appears that my trick (from comment 9) doesn't work anymore in the 3.8.13 kernel...No idea why it worked in older kernels (3.8.8) and not this one... I have also verified that after this issue happens, the shutdown -r command will not work because the ethernet device does not come back up on reboot. Instead, you must do a shutdown -h to power off and then physically power on again in order for the device to work on boot (for some unknown reason).
I have now confirmed that my trick (from comment 9) does indeed work every time for the 3.8.11 kernel but NOT for the 3.8.13 kernel. # uname -a Linux xxxxx.com 3.8.11-100.fc17.x86_64 #1 SMP Wed May 1 19:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux I have removed newer kernels and reverted back to the 3.8.11 until this bug is definitely fixed in a new kernel.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
Note that the following causes the problem: 1. close lid, detatch power, ethernet cable. 2. re-attach power cable 3. open lid Whereas this does not: 1. close lid, detatch power, ethernet cable. 2. open lid 3. re-attach power cable Something about attaching the power cable before it resumes from standby causes this problem.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. It has been over a month since we asked you to test the 3.11 kernel updates and let us know if your issue has been resolved or is still a problem. When this happened, the bug was set to needinfo. Because the needinfo is still set, we assume either this is no longer a problem, or you cannot provide additional information to help us resolve the issue. As a result we are closing with insufficient data. If this is still a problem, we apologize, feel free to reopen the bug and provide more information so that we can work towards a resolution If you experience different issues, please open a new bug report for those.
Please close this bug.