r8169 is set to 100Mb/s after suspending at 1000Mb/s

[Brian J. Murrell]

I have an r8169 gige card in this machine which links at 1000Mb/s just fine when powered on, however after a suspend/resume cycle, it will be linked at 100Mb/s. This is obviously a problem with the driver but a handy workaround is to just create a file in /etc/pm/config.d/r8169 with:

# r8169 driver resumes at 100Mb/s. reloading it brings it back to 1000Mb/s
SUSPEND_MODULES="r8169"

in it.

I consider this a bug in both the driver itself and PM for lack of a functioning workaround while the driver is fixed.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: linux-image-2.6.32-28-generic 2.6.32-28.55
Regression: No
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.32-28.55-generic 2.6.32.27+drm33.12
Uname: Linux 2.6.32-28-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
Architecture: i386
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/dsp1', '/dev/dsp', '/dev/snd/by-id', '/dev/snd/controlC1', '/dev/snd/pcmC1D0c', '/dev/snd/controlC0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/pcmC0D1c', '/dev/snd/pcmC0D2p', '/dev/snd/by-path', '/dev/snd/seq', '/dev/snd/timer', '/dev/sequencer2', '/dev/sequencer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'nForce2'/'NVidia nForce2 with ALC650E at irq 20'
   Mixer name : 'Realtek ALC650E'
   Components : 'AC97a:414c4722'
   Controls : 50
   Simple ctrls : 33
Card1.Amixer.info:
 Card hw:1 'U0x20400x7200'/'USB Device 0x2040:0x7200 at usb-0000:00:02.2-1, high speed'
   Mixer name : 'USB Mixer'
   Components : 'USB2040:7200'
   Controls : 1
   Simple ctrls : 1
Card1.Amixer.values:
 Simple mixer control 'Digital In',0
   Capabilities: cswitch cswitch-joined penum
   Capture channels: Mono
   Mono: Capture [on]
Date: Thu Mar 10 06:43:36 2011
IwConfig:
 lo no wireless extensions.

 eth1 no wireless extensions.

 eth0 no wireless extensions.
Lsusb:
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 002: ID 2040:7200 Hauppauge
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.32-28-generic root=/dev/mapper/rootvol_tmp-ubuntu_root ro console=ttyS0,115200 console=tty0 resume=/dev/mapper/rootvol-swap quiet splash
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
RelatedPackageVersions: linux-firmware 1.34.3
RfKill:

SourcePackage: linux
dmi.bios.date: 11/22/2004
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: NF7-S/NF7,NF7-V (nVidia-nForce2)
dmi.board.vendor: http://www.abit.com.tw/
dmi.board.version: 2.X,1.0
dmi.chassis.type: 3
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd11/22/2004:svn:pn:pvr:rvnhttp//www.abit.com.tw/:rnNF7-S/NF7,NF7-V(nVidia-nForce2):rvr2.X,1.0:cvn:ct3:cvr:

[Laurentiu (laurentiu-redhat-bugs)]

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.

[Dan (dan-redhat-bugs)]

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.

[Laurentiu (laurentiu-redhat-bugs)]

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.

[Bug (bug-redhat-bugs)]

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

[Per (per-redhat-bugs)]

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.

[Bug (bug-redhat-bugs)]

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

[Stanislaw (stanislaw-redhat-bugs)]

Please attach dmesg when problem happens.

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

[Laurentiu (laurentiu-redhat-bugs)]

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

[Stanislaw (stanislaw-redhat-bugs)]

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 ?

[Francois (francois-redhat-bugs)]

It is sensible.

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

--
Ueimor

[Stanislaw (stanislaw-redhat-bugs)]

Created attachment 454034
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.

[Stanislaw (stanislaw-redhat-bugs)]

Here is kernel build with above patch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2540097

Laurentiu, please test.

[Francois (francois-redhat-bugs)]

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

[Laurentiu (laurentiu-redhat-bugs)]

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.

[Pierre (pierre-redhat-bugs)]

What's the status of this bug? The patch doesn't seem to be in the normal kernels yet.

[Francois (francois-redhat-bugs)]

It's in Linus's tree as fccec10b33503a2b1197c8e7a3abd30443bedb08

I'll push it to stable today.

--
Ueimor

[Francois (francois-redhat-bugs)]

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

[Pierre (pierre-redhat-bugs)]

Fantastic!

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

[Stanislaw (stanislaw-redhat-bugs)]

*** Bug 505561 has been marked as a duplicate of this bug. ***

[Fedora (fedora-redhat-bugs)]

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

[Fedora (fedora-redhat-bugs)]

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

[Pierre (pierre-redhat-bugs)]

Confirmed working with 2.6.34.7-63.fc13.x86_64.

[Fedora (fedora-redhat-bugs)]

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.

[Fedora (fedora-redhat-bugs)]

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.

[Jeff (jeff-redhat-bugs)]

Also confirmed, working with 2.6.37-0.rc7.git0.2.fc15.x86_64

[Brian J. Murrell (brian-interlinx)]

A fix for this was committed upstream in commit fccec10b33503a2b1197c8e7a3abd30443bedb08 (http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob;f=queue-2.6.36/r8169-re-init-phy-on-resume.patch;h=0d3c3fd41e5245d855214b0e5e1b4723a959a578;hb=9a58d64e7fec813c5a03ee1c69148e579d0ddf80) per http://<email address hidden>/msg00420.html:

This is a note to let you know that I've just added the patch titled

    r8169: (re)init phy on resume

to the 2.6.36-stable tree...

[Jeremy Foshee (jeremyfoshee)]

Hi Brian,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]