Bug 502974 - Realtek r8169 gigabit ethernet resumes from sleep in 100Mbs mode
Summary: Realtek r8169 gigabit ethernet resumes from sleep in 100Mbs mode
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Stanislaw Gruszka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 505561 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-05-28 02:32 UTC by Laurentiu Badea
Modified: 2011-02-05 21:03 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-02-05 21:03:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
f13-r8169-init-phy-when-resume.patch (934 bytes, text/plain)
2010-10-18 08:05 UTC, Stanislaw Gruszka
no flags Details

Description Laurentiu Badea 2009-05-28 02:32:33 UTC
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.

How reproducible:
Every time

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

Actual results:
eth0 remained in 100Mbps mode after wake up

Expected results:
eth0 should have renegotiated to 1000Mbps

Additional info:
"ethtool -s eth0 autoneg on" after sleep causes the port to go in 1000Mbps again.

Comment 1 Dan Williams 2009-05-28 18:32:11 UTC
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.

Comment 2 Laurentiu Badea 2009-05-29 02:28:08 UTC
This is a fresh Fedora 11 Preview install.

ifcfg-eth0 contains the basic stuff

# Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:14:d1:12:34:56
ONBOOT=yes

The card is a TRENDnet PCITXR.

Comment 3 Bug Zapper 2009-06-09 16:42:25 UTC
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 4 Per Nystrom 2009-09-12 17:12:23 UTC
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.

Comment 5 Bug Zapper 2010-04-27 14:33:22 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 6 Stanislaw Gruszka 2010-09-24 22:39:00 UTC
Please attach dmesg when problem happens.

Does problem still occurs on up-to-date kernels (F-13, F-14 or upstream)?

Comment 7 Laurentiu Badea 2010-10-03 23:49:37 UTC
Problem still happens with 2.6.34.7-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

NetworkManager verbiage:
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)
[...]

Comment 8 Stanislaw Gruszka 2010-10-04 15:45:55 UTC
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 ?

Comment 9 Francois Romieu 2010-10-04 21:23:25 UTC
It is sensible.

I will consider ourselves lucky if an extra rtl8169_init_phy() is not
needed before long either.

-- 
Ueimor

Comment 10 Stanislaw Gruszka 2010-10-18 08:05:52 UTC
Created attachment 454034 [details]
f13-r8169-init-phy-when-resume.patch

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.

Comment 11 Stanislaw Gruszka 2010-10-18 08:35:11 UTC
Here is kernel build with above patch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2540097

Laurentiu, please test.

Comment 12 Francois Romieu 2010-10-18 21:05:48 UTC
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.

-- 
Ueimor

Comment 13 Laurentiu Badea 2010-10-19 04:28:45 UTC
I can confirm that with 2.6.34.7-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.

Comment 14 Pierre Ossman 2010-11-24 21:32:09 UTC
What's the status of this bug? The patch doesn't seem to be in the normal kernels yet.

Comment 15 Francois Romieu 2010-11-24 22:11:06 UTC
It's in Linus's tree as fccec10b33503a2b1197c8e7a3abd30443bedb08

I'll push it to stable today.

-- 
Ueimor

Comment 16 Francois Romieu 2010-11-25 00:01:03 UTC
I have submitted it for 2.6.36.1+.

Four patches are available for (now closed) 2.6.34.7 at :

http://userweb.kernel.org/~romieu/r8169/2.6.34.7/

-- 
Ueimor

Comment 17 Pierre Ossman 2010-11-25 20:56:54 UTC
Fantastic!

Stanislaw, can we get this into the stable F13 and F14 kernel?

Comment 18 Stanislaw Gruszka 2010-11-26 13:11:21 UTC
*** Bug 505561 has been marked as a duplicate of this bug. ***

Comment 19 Fedora Update System 2010-12-03 15:34:15 UTC
kernel-2.6.34.7-63.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/kernel-2.6.34.7-63.fc13

Comment 20 Fedora Update System 2010-12-03 15:38:12 UTC
kernel-2.6.35.9-64.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/kernel-2.6.35.9-64.fc14

Comment 21 Pierre Ossman 2010-12-04 13:48:23 UTC
Confirmed working with 2.6.34.7-63.fc13.x86_64.

Comment 22 Fedora Update System 2010-12-05 00:42:16 UTC
kernel-2.6.35.9-64.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2010-12-07 20:07:11 UTC
kernel-2.6.34.7-63.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Jeff Layton 2011-01-02 12:49:13 UTC
Also confirmed, working with 2.6.37-0.rc7.git0.2.fc15.x86_64


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