Description of problem: I have Windows Vista and Fedora 10 installed. Every time I used windows as the last OS and then boot linux I can't use my ethernet card (to connect over the router to the internet). It seems that windows deactivates the card somehow and because of that Fedora can't use it on the next start. Version-Release number of selected component (if applicable): Windows Version: Vista Home Premium ethernet card: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet Controller (rev 01) How reproducible: Steps to Reproduce: 1. start windows and reboot 2. start linux Actual results: It is definite that the bug occurs every time I used windows as the last OS but when you used linux the last time and reboot the system then you can use the ethernet card again. Futhermore under linux my ethernet card doesn't automatically get an IP from my dhcp-router although it works fine under windows so I have to choose an own IP (with ifconfig) and I have to choose the router as gateway manually (with route). (I don't know if this is important but I had to write my router's IP as nameserver to the /etc/resolv.conf because this file was empty up to comments) Expected results: Fedora should (imho) take care of the ethernet card and that it is activated when linux boots and configure the IP from the dhcp-server. Additional info:
I confirm this problem on my computer with exactly the same hardware (even revision). The other RTL 8139 is working fine and does not seems to be affected by this issue. Looks like Windows is setting the card on hibernate or shutdown into a mode linux, does not know to handle.
What's the output of 'lspci' and 'ethtool eth0' under linux when this problem occurs?
ethtool eth0 issues: Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) Link detected: yes and lspci: 00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge 00:02.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Graphics Port 0) 00:04.0 PCI bridge: ATI Technologies Inc Device 7914 00:05.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 1) 00:06.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 2) 00:07.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3) 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) 00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14) 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge 00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: ATI Technologies Inc M76 [Radeon Mobility HD 2600 Series] 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) 07:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01) 08:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05) 08:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 08:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12) 08:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 08:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)
Thanks for filling this bug. The issues with the r8169 driver are only appears on some dual boot Windows/Linux systems. Windows by defaults disables the NIC at Windows shutdown time in order to disable Wake-On-Lan, and this NIC will remain disabled until the next time Windows turns it on. The r8169 driver in the kernel does not know how to turn the NIC on from this disabled state; therefore, the device will not respond, even if the driver loads and reports that the device is up. Workaround for this problem: Enable the feature "Wake-on-lan after shutdown". You can set this options through the Windows device manager. Can you please give it a try and give us feedback? Thank you. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(my vista is in german so the titles in the following text are translated into english and could differ from the original titles) I found this: rightclicked my NIC and found a option called "wake-on-lan-functions" under the tab "advanced". the set value there was "pattern match & magic package" so it seems that it was already enabled. and despite of this setting there is the bug after windows has been shut down. i didn't find any other feature that would be similar to "Wake-on-lan after shutdown"... did you mean this option above (which i described) ?
Created attachment 340253 [details] settings for WOL on XP system (in German) Due a lack of the hardware and mainly of windows I'm dependent on statements of others. It seams that that tip above is done on xp and not vista. Maybe you can download the windows driver from the Realtek website and see if the option is available on Vista. Or try with the options that Vista offers you. Another alternative maybe to test the issue with rawhide (live cd or similar) or try enable fedora-updates-testing repo (enable=1 in etc/yum.repos.d/fedora-updates-testing.repo) to get a newer kernel. Since 2.6.28 are some improvements on the r8169 driver. Anyway, most likely it's a bug within the driver/kernel and not with NetworkManager. Hence it could be a good idea assigning this to the kernel component and hope that the kernel maintainers get a clue.
According to this: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ca52efd5490f97f396d3c5863ba714624f272033 There is some chance that this is fixed in newer kernels. Reporter, can you test Fedora Rawhide snapshot from: http://alt.fedoraproject.org/pub/alt/nightly-composes/ and see if it's still an issue?
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days