Bug 505561 - Realtek RTL 8111C fails to autonegotiate at 1000 Full or to respond to WOL signal
Realtek RTL 8111C fails to autonegotiate at 1000 Full or to respond to WOL si...
Status: CLOSED DUPLICATE of bug 502974
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-12 09:08 EDT by Jeff Layton
Modified: 2014-06-18 03:38 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-26 08:11:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ethtool and lspci info taken with r8168.ko in use (3.77 KB, text/plain)
2009-06-12 09:08 EDT, Jeff Layton
no flags Details
davem's net-next r8169 driver + wol suspend fix (12.99 KB, patch)
2009-06-12 19:00 EDT, Francois Romieu
no flags Details | Diff

  None (edit)
Description Jeff Layton 2009-06-12 09:08:56 EDT
Created attachment 347559 [details]
ethtool and lspci info taken with r8168.ko in use

I've recently purchased a Biostar TA790GX motherboard that has a built in RTL 8111C interface. There are 2 problems when using the stock driver in current F11 kernel (kernel-2.6.29.4-167.fc11.x86_64):

1) it always fails to negotiate at 1000 full -- only at 100 full. If I use ethtool to force the interface to 1000Mb/s, then it will stay at that setting and seems to be stable.

2) wake on lan does not work whenever the machine is suspended or shut down cleanly

I've built and installed the 8168.ko from realtek's website (r8168-8.012.00), and it seems to fix the first problem. With that module, the interface autonegotiates to 1000 full with no problem.

The second problem exists even with the vendor driver. I know however that WOL does work with this card. I can start up the machine and then hold down the power button so that it powers off while waiting at the grub menu. After it powers off, the box will then wake on lan properly.

Attached is ethtool and lspci info taken with the 8168 driver plugged in. Let me know if any other info is needed.
Comment 1 Francois Romieu 2009-06-12 19:00:54 EDT
Created attachment 347680 [details]
davem's net-next r8169 driver + wol suspend fix

Can you try this patch against 2.6.30 ?

It may make a difference for 1) and it should fix the suspend part of 2).

Some feedback regarding the shutdown part of 2) with the patch would be
welcome too.

Thanks.

-- 
Ueimor
Comment 2 Jeff Layton 2009-06-13 08:02:50 EDT
Installed a 2.6.30 kernel on the box from here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=105938

That kernel without the patch seems to fix the autonegotiate problem. It negotiated to 1000 every time with it. Autonegotiate still seemed to work correctly with that patch installed too.

Unfortunately, the machine would suspend with that kernel but I could never wake it up again, even by pushing the power button. WOL didn't work either. I suspect that that problem is unrelated to the network driver.

I shut down the box cleanly, and then tried to use WOL to wake it up. It didn't work. So, I then built an r8169 module with that patch and shut down the box with that module installed. WOL still didn't work.

In conclusion:

1) the autonegotiate problem seems to have been fixed already in the 2.6.30 kernel, AFAICT.

2) I can't really test whether the patch helps WOL from suspend since suspend seems to be completely borked for me in 2.6.30. It definitely does not help the box WOL from a complete shutdown.

When I get some more time, I'll open a BZ for the 2.6.30 suspend problem. If I can get that resolved then I may be able to better test this patch.
Comment 3 Chuck Ebbert 2009-06-16 00:24:22 EDT
I'm guessing commit f21b75e9d6471d7f4e2110774819be7beafc86d5 fixes problems for a lot of different r8169 cards, maybe that fixed this one?
Comment 4 Chuck Ebbert 2009-06-16 10:13:51 EDT
(In reply to comment #3)
> I'm guessing commit f21b75e9d6471d7f4e2110774819be7beafc86d5 fixes problems for
> a lot of different r8169 cards, maybe that fixed this one?  

That went in after 2.6.30 final. Jeff, can you try adding pci=nomsi to your boot options on 2.6.29 and see if that helps?
Comment 5 Jeff Layton 2009-06-16 14:08:01 EDT
Adding pci=nomsi to the boot options didn't seem to make any difference.

I should also clarify that on initial bootup, the interface will usually negotiate to 1000Mb, but after suspend/wake cycle it goes down to 100Mb.
Comment 6 Jeff Layton 2009-07-29 08:20:38 EDT
I finally got around to testing a newer kernel. I went ahead and grabbed the latest bleeding edge f12 build out of koji:

kernel-2.6.31-0.107.rc4.git3.fc12.x86_64

Suspend and resume work properly with this kernel, and it seems to autonegotiate to 1000 Full properly. WoL still does not work with it however. I tried applying the patch in comment #1 but it doesn't apply cleanly.

Francois, is the patch in comment #1 in recent mainline git? I had a look at the git logs and didn't see that exact patch though there were some other fixes in this area.
Comment 7 Francois Romieu 2009-07-29 15:03:04 EDT
jlayton :
[...]
> Francois, is the patch in comment #1 in recent mainline git? I had a look at
> the git logs and didn't see that exact patch though there were some other fixes
> in this area.  

The patch is included through f21b75e9d6471d7f4e2110774819be7beafc86d5
and 3577aa1bd7efc9c474f59738d2fb89c168168d55 but your 8168 needs the (really,
really) recent ca52efd5490f97f396d3c5863ba714624f272033 for WoL to work after
shutdown (see http://bugzilla.kernel.org/attachment.cgi?id=22477 from
http://bugzilla.kernel.org/show_bug.cgi?id=9512).

It may still not negotiate 1000 Mbps after resume though, at least until you
use ethtool.

Does it clarify ?

-- 
Ueimor
Comment 8 Jeff Layton 2009-08-01 10:54:21 EDT
It looks like ca52efd5490f97f396d3c5863ba714624f272033 was already in the kernel that I tested in comment #6. It was built from a very recent git tree.

I guess we can conclude that WoL still doesn't work even with very recent upstream kernels. Is there any info I can gather that might be helpful? I can also test patches if you need me to.
Comment 9 Per Nystrom 2009-09-12 20:29:58 EDT
I am experiencing similar problems -- speed is always 100 Mb/sec after resume, and WOL with magic packets doesn't work.

I have an MSI K9A2 motherboard with a Realtek 8111B:

# lspci | grep -i eth
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

I have the latest kernel from F11 updates:

# uname -r
2.6.30.5-43.fc11.x86_64

WOL with magic packets seems to work fine with Realtek's r8168 driver, which I downloaded from http://www.realtek.com.tw/, but the speed also comes back at 100 Mb/sec.  In either case I can force it back to 1000 Mb/sec with ethtool -s eth0 speed 1000.

By the way, WOL *does* work under either driver for physical activity, i.e: ethtool -s eth0 wol p
Comment 10 Per Nystrom 2009-09-30 20:17:15 EDT
Still the same behavior with the latest kernel update:

# uname -r
2.6.30.8-64.fc11.x86_64
Comment 11 Alec Leamas 2009-11-11 16:03:14 EST
Same on a Gigabyte GA-MA770-UD3 mobo with a separate  TP-LINK TG3468 
card (the mobo has no native support for wol, but the card has).

$ uname -r: 2.6.30.9-96.fc11.x86_64

With Fedora stock driver, the link negotiates to 100 MB/s and wol don't work. With the Realtek driver, both problems are resolved. BTW, this driver seems to GPLv2.

Driver url: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=5&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#RTL8111B/RTL8168B/RTL8111/RTL8168%3Cbr%3ERTL8111C/RTL8111CP/RTL8111D(L)%3Cbr%3ERTL8168C/RTL8111DP

This is also an Ubuntu bug, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/160413. Note the 55Networking attachment being part of the solution how to use the driver.
Comment 12 Jeff Layton 2009-11-18 08:44:02 EST
Going ahead and moving this to F12 bug since similar problems persist there.

I'm using the r8169.ko driver with kernel-2.6.31.5-127.fc12.x86_64.

The symptoms are slightly different now for me. After a fresh reboot (cold or warm), the link negotiates to 1000 Full. After a suspend and resume, it only negotiates to 100 Full.

WOL still does not work at all, either when the machine is suspended or after cold shutdown.

Here's ethtool after a warm reboot:

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: 1000Mb/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 here it is after suspend and resume:

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 
	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

...the obvious difference here is the "Advertised link modes". Perhaps fixing the driver to add 1000baseT modes on resume might fix the autonegotiation problem?

The WOL problem, I'm less sure about -- let me know if there's any other info I can help gather to troubleshoot that.
Comment 13 Steve Schaeffer 2010-01-05 19:13:25 EST
Also seeing this problem with:

# uname -r
2.6.31.9-174.fc12.i686.PAE

# lspci | grep -i eth
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)

Gigabit speed is restored when issuing:
# ethtool -s eth0 speed 1000
Comment 14 Solomon Peachy 2010-02-05 12:08:26 EST
This problem also affects my laptop.   Unloading/reloading the module fixes the advertised link speeds.

This bug is still present in the 2.6.32.7-37.fc12.x86_64 kernel.

there's an upstream bug ticket about it, with more details about my setup:

http://bugzilla.kernel.org/show_bug.cgi?id=10130
Comment 15 Solomon Peachy 2010-06-08 10:00:51 EDT
The link speed bug is still present in the 2.6.33.5-112.fc13.x86_64 kernel.  No activity upstream on this, unfortunately.
Comment 16 Per Nystrom 2010-07-03 19:46:52 EDT
This bug is still present in F13.

# uname -r
2.6.33.5-124.fc13.x86_64
Comment 17 Volnei 2010-07-22 07:44:59 EDT
This bug is also present in Fedora 13 x86_64

2.6.33.6-147.fc13.x86_64
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
        Subsystem: Intel Corporation Device D608
        Kernel driver in use: r8169
        Kernel modules: r8169

The network inteface not negotiate the speed of 1000mb / s.
Only allows up to 100mb / s

mii-tool-v eth0
eth0: negotiated 100baseTx-FD flow-control, link ok
  product info: vendor 00:07:32, model 17 rev 2
  basic mode: autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT 1000baseT-HD-FD-FD 100baseTx 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising: 100baseTx 100baseTx-FD-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 1000baseT 1000baseT-HD-FD-FD 100baseTx 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Comment 18 Volnei 2010-07-26 10:22:55 EDT
Hi,

I wonder what is being done to solve this problem and if there is any provision to fix it.


With the intension to help in any way I am sending more information:

mainboard: INTEL DG31PR

00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 02)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 01)
00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation N10/ICH7 Family SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:05.0 Ethernet controller: Sundance Technology Inc / IC Plus Corp IC Plus IP100A Integrated 10/100 Ethernet MAC + PHY (rev 31

modinfo r8169
filename:       /lib/modules/2.6.33.6-147.fc13.x86_64/kernel/drivers/net/r8169.ko
version:        2.3LK-NAPI
license:        GPL
description:    RealTek RTL-8169 Gigabit Ethernet driver
author:         Realtek and the Linux r8169 crew <netdev@vger.kernel.org>
srcversion:     05017E29F315E16C9C34D12
alias:          pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias:          pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias:          pci:v000016ECd00000116sv*sd*bc*sc*i*
alias:          pci:v00001259d0000C107sv*sd*bc*sc*i*
alias:          pci:v00001186d00004300sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008169sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008168sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008167sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008136sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008129sv*sd*bc*sc*i*
depends:        mii
vermagic:       2.6.33.6-147.fc13.x86_64 SMP mod_unload 
parm:           rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm:           use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm:           debug:Debug verbosity level (0=none, ..., 16=all) (int)

 ethtool eth0
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 pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
        Link partner advertised pause frame use: No
        Link partner 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

Thanks
Comment 19 Andy Gospodarek 2010-07-26 10:53:34 EDT
(In reply to comment #18)
> Hi,
> 
> I wonder what is being done to solve this problem and if there is any provision
> to fix it.
> 
> 

[snip]

>         Link partner advertised link modes:  10baseT/Half 10baseT/Full 
>                                              100baseT/Half 100baseT/Full 
>         Link partner advertised pause frame use: No
>         Link partner advertised auto-negotiation: Yes
>         Speed: 100Mb/s
>         Duplex: Full

If you are hoping to connect at 1000Mbps, you will need to connect to a different switch or port that operates at 1000Mbps.  The information above indicates that the link partner (the device at the other end of the cable) only supports 10/100Mbps.
Comment 20 Jeff Layton 2010-07-26 11:09:39 EDT
It looks that way, but I suspect that that is a driver bug. On my computer, here's ethtool output after a fresh reboot:

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 pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/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

Then, after a suspend/resume:

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 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	Link partner advertised pause frame use: No
	Link partner 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
Comment 21 Jeff Layton 2010-07-26 11:14:32 EDT
Also, changing to f13 since problem still persists there.
Comment 22 Andy Gospodarek 2010-07-26 11:43:50 EDT
Ah, ok.  Good to know.
Comment 23 Volnei 2010-07-26 14:47:29 EDT
Hi,

This is really a bug in the kernel module, because unfortunately in Window $, it works perfectly.
Works with Windows 7 64 and 32bit on the same mainboard DG31PR with interface concerned.

I did several tests, using the same cable Cat 5e and 3Com 3CBLUG24A.
All Linux machines that don't use interface realtek works on 1Gb/s.
Comment 24 Stanislaw Gruszka 2010-11-26 08:11:21 EST

*** This bug has been marked as a duplicate of bug 502974 ***

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