Bug 494392 - [r8169, WOL] Every time I used windows as the last OS and then boot linux I can't use my ethernet card [NEEDINFO]
[r8169, WOL] Every time I used windows as the last OS and then boot linux I c...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
i686 Other
low Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-06 13:13 EDT by bumbelejer
Modified: 2009-12-18 04:12 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 04:12:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
arxs: needinfo? (bumbelejer)


Attachments (Terms of Use)
settings for WOL on XP system (in German) (58.45 KB, image/jpeg)
2009-04-19 16:11 EDT, Niels Haase
no flags Details

  None (edit)
Description bumbelejer 2009-04-06 13:13:14 EDT
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:
Comment 1 Florian Sievert 2009-04-07 05:01:17 EDT
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.
Comment 2 Dan Williams 2009-04-08 21:27:11 EDT
What's the output of 'lspci' and 'ethtool eth0' under linux when this problem occurs?
Comment 3 bumbelejer 2009-04-09 14:19:13 EDT
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)
Comment 4 Niels Haase 2009-04-17 10:39:06 EDT
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
Comment 5 bumbelejer 2009-04-19 11:59:04 EDT
(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) ?
Comment 6 Niels Haase 2009-04-19 16:11:39 EDT
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.
Comment 7 Vedran Miletić 2009-10-08 06:48:17 EDT
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?
Comment 8 Bug Zapper 2009-11-18 06:42:00 EST
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
Comment 9 Bug Zapper 2009-12-18 04:12:35 EST
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.

Note You need to log in before you can comment on or make changes to this bug.