Red Hat Bugzilla – Bug 502974
Realtek r8169 gigabit ethernet resumes from sleep in 100Mbs mode
Last modified: 2011-02-05 16:03:10 EST
Description of problem:
Gigabit ethernet card resumes from Sleep state in 100Mbs mode.
Version-Release number of selected component (if applicable):
eth0: PCI RTL8169sb Gigabit ethernet card (connected, 1000Mbps mode)
eth1: Onboard Intel 10/100 ethernet (unconnected)
(dmesg indicated it had renamed eth0 as eth1)
Netgear DS608 8-port Gigabit switch.
Steps to Reproduce:
1. eth0 is in 1000Mbps mode
2. put system in Sleep mode (eth0 switches to 100Mbps mode according to switch)
3. wake up
eth0 remained in 100Mbps mode after wake up
eth0 should have renegotiated to 1000Mbps
"ethtool -s eth0 autoneg on" after sleep causes the port to go in 1000Mbps again.
Do you have an /etc/sysconfig/network-scripts/ifcfg-eth0 file? If so, what's in it? This is probably a kernel driver issue though, since NM doesn't actually touch any of these layer 1/layer 2 details at this time.
This is a fresh Fedora 11 Preview install.
ifcfg-eth0 contains the basic stuff
# Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
The card is a TRENDnet PCITXR.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I have the same problem, Fedora 11, latest updates as of today.
# lspci | grep -i eth
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
Also, the adapter does not wake on lan using magic packets, though it will respond to broadcast or physical activity.
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. 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 '11'.
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 11'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 11 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:
Please attach dmesg when problem happens.
Does problem still occurs on up-to-date kernels (F-13, F-14 or upstream)?
Problem still happens with 126.96.36.199-56.fc13.i686.PAE. Probably related: when the system goes on standby, the ethernet port turns off briefly then turns back on in low-speed mode, probably for WOL purposes.
The kernel messages on resume associated with the network driver are as follows:
r8169 0000:03:03.0: PME# enabled
r8169 0000:03:03.0: restoring config space at offset 0x5 (was 0x0, writing 0xdf9fff00)
r8169 0000:03:03.0: restoring config space at offset 0x4 (was 0x1, writing 0xdc01)
r8169 0000:03:03.0: restoring config space at offset 0x3 (was 0x0, writing 0x4008)
r8169 0000:03:03.0: restoring config space at offset 0x1 (was 0x2b80000, writing 0x2b00117)
r8169 0000:03:03.0: PME# disabled
r8169 0000:03:03.0: eth0: link up
wake requested (sleeping: yes enabled: yes)
<info> waking up and re-enabling...
<info> (eth0): now managed
<info> (eth0): device state change: 1 -> 2 (reason 2)
<info> (eth0): bringing up device.
<info> (eth0): preparing device.
<info> (eth0): deactivating device (reason: 2).
<info> (eth0): carrier now ON (device state 2)
<info> (eth0): device state change: 2 -> 3 (reason 40)
<info> Activation (eth0) starting connection 'System eth0'
<info> (eth0): device state change: 3 -> 4 (reason 0)
I would tell we need to put rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL) somewhere in resume procedure.
Francois, what you think ?
It is sensible.
I will consider ourselves lucky if an extra rtl8169_init_phy() is not
needed before long either.
Created attachment 454034 [details]
Proposed fix. I tested similar patch on upstream kernel. I'm not able to reproduce the bug, but putting device in 10 Mb/s before suspend give me 100 Mb/s after resume - correct value for that connection.
I'm not sure if we should not reset save the speed at suspend, and restore that value at resume instead of max speed.
Here is kernel build with above patch:
Laurentiu, please test.
Stanislaw Gruszka :
> I'm not sure if we should not reset save the speed at suspend, and restore that
> value at resume instead of max speed.
It would amount to supposing that the switch stays the same, imho defeating
the whole purpose of auto-negotiation. I would rather see the do-not-autoneg-
because-my-swithc-is-broken-or-my-setup-does-not-change an option rather than
the default behavior.
I can confirm that with 188.8.131.52-59.bz502974.fc13.i686.PAE linked above the system resumes from sleep at 1000Mbps.
As for whether autoneg should be enabled rather than saved/restored, my 2c: given that it's not something you set accidentally, we have to assume someone knows what they are doing, so it may be bad form to second-guess the user and force it back on. But hey, I'm good either way, my problem is solved.
What's the status of this bug? The patch doesn't seem to be in the normal kernels yet.
It's in Linus's tree as fccec10b33503a2b1197c8e7a3abd30443bedb08
I'll push it to stable today.
I have submitted it for 184.108.40.206+.
Four patches are available for (now closed) 220.127.116.11 at :
Stanislaw, can we get this into the stable F13 and F14 kernel?
*** Bug 505561 has been marked as a duplicate of this bug. ***
kernel-18.104.22.168-63.fc13 has been submitted as an update for Fedora 13.
kernel-22.214.171.124-64.fc14 has been submitted as an update for Fedora 14.
Confirmed working with 126.96.36.199-63.fc13.x86_64.
kernel-188.8.131.52-64.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
kernel-184.108.40.206-63.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Also confirmed, working with 2.6.37-0.rc7.git0.2.fc15.x86_64