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.
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
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.
I'm guessing commit f21b75e9d6471d7f4e2110774819be7beafc86d5 fixes problems for a lot of different r8169 cards, maybe that fixed this one?
(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?
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.
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.
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
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.
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
Still the same behavior with the latest kernel update: # uname -r 2.6.30.8-64.fc11.x86_64
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.
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.
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
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
The link speed bug is still present in the 2.6.33.5-112.fc13.x86_64 kernel. No activity upstream on this, unfortunately.
This bug is still present in F13. # uname -r 2.6.33.5-124.fc13.x86_64
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
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.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
(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.
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
Also, changing to f13 since problem still persists there.
Ah, ok. Good to know.
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.
*** This bug has been marked as a duplicate of bug 502974 ***