Hi, i have a 3 PC's with Realtek's r8169 PCI card. Since kernel 2.6.18-r1 the network speed is at a maximum of 100mit, even though ethtool shows the card at 1000mbit full duplex. When reverting to 2.6.17-r8 everything works at full speed again. I can confirm that the problem has to do with the support for RTL8168 ethernet which was added in 2.6.18-r1 (4010_r8169-8168.patch). Compiling the kernel without this patch resulted in my r8169 working at full speed again. Turning NAPI on or off didn't make a difference.
Please post "lspci" and "lspci -n" output
# lspci 00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev a2) 00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev a2) 00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev a2) 00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev a2) 00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev a2) 00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev a2) 00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a3) 00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2) 00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3) 00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3) 00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3) 00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1) 00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio Processing Unit (rev a2) 00:06.0 Multimedia audio controller: nVidia Corporation nForce2 AC97 Audio Controler (MCP) (rev a1) 00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3) 00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2) 00:0d.0 FireWire (IEEE 1394): nVidia Corporation nForce2 FireWire (IEEE 1394) Controller (rev a3) 00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev a2) 01:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) 01:0b.0 RAID bus controller: Promise Technology, Inc. PDC20376 (FastTrak 376) (rev 02) 03:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600/GeForce 6600 GT] (rev a2) # lspci -n 00:00.0 0600: 10de:01e0 (rev a2) 00:00.1 0500: 10de:01eb (rev a2) 00:00.2 0500: 10de:01ee (rev a2) 00:00.3 0500: 10de:01ed (rev a2) 00:00.4 0500: 10de:01ec (rev a2) 00:00.5 0500: 10de:01ef (rev a2) 00:01.0 0601: 10de:0060 (rev a3) 00:01.1 0c05: 10de:0064 (rev a2) 00:02.0 0c03: 10de:0067 (rev a3) 00:02.1 0c03: 10de:0067 (rev a3) 00:02.2 0c03: 10de:0068 (rev a3) 00:04.0 0200: 10de:0066 (rev a1) 00:05.0 0401: 10de:006b (rev a2) 00:06.0 0401: 10de:006a (rev a1) 00:08.0 0604: 10de:006c (rev a3) 00:09.0 0101: 10de:0065 (rev a2) 00:0d.0 0c00: 10de:006e (rev a3) 00:1e.0 0604: 10de:01e8 (rev a2) 01:08.0 0200: 10ec:8169 (rev 10) 01:0b.0 0104: 105a:3376 (rev 02) 03:00.0 0300: 10de:00f1 (rev a2)
Still reproducible on 2.6.19?
Yesterday i tried gentoo-sources-2.6.19-r2. Unfortunately the problem is still the same. I can post iperf output on both the affected and unaffected version if that is of any help. I also tried vanilla-sources, the problem does not occur with them.
Problem doesn't occur with vanilla-sources-2.6.19?
As far as I can remember it didn't occour with vanilla-sources-2.6.18. I will try with vanilla-sources-2.6.19 tonight and report back.
(In reply to comment #6) > As far as I can remember it didn't occour with vanilla-sources-2.6.18. I will > try with vanilla-sources-2.6.19 tonight and report back. > Interesting, the card works at full speed with vanilla-sources-2.6.18.2. But with vanilla-sources-2.6.19.1 it has the same problem that >=2.6.18-gentoo-r1 has. Seems to be an upstream problem.
Indeed, but your diagnosis found the exact commit where the problem was introduced. Please report this bug at http://bugzilla.kernel.org and post the new URL here. I will add the more specific details shortly after.
Any news on this?
Actually, you should test 2.6.20-rc3 before reporting as there have been several bugs fixed.
i've not yet found time to report or test it, i will try 2.6.20-rc3 and report back in a few days.
any news on 2.6.20-rc testing?
yes, i've tried 2.6.20-rc3 and i couldn't get a reliable connection at all. there seems to be some heavy work going on with the driver.
Can you test -rc6 and file an upstream bug if it is still broken there?
2.6.20 is out now, any news?
ok, i've tried 2.6.20 and ran into the same problems. then i remembered that i had enabled jumbo frames and set the mtu to 7000. after setting the mtu to 1500 the connection worked, but very slow in one direction: [ 5] local 192.168.16.11 port 58650 connected with 192.168.16.2 port 5001 [ 4] local 192.168.16.11 port 5001 connected with 192.168.16.2 port 43273 [ 5] 0.0-10.0 sec 607 MBytes 509 Mbits/sec [ 4] 0.0-10.0 sec 62.8 MBytes 52.8 Mbits/sec then i figured out that the connection is fast again if i set the mtu to 7100: [ 5] local 192.168.16.11 port 58652 connected with 192.168.16.2 port 5001 [ 5] 0.0-10.0 sec 868 MBytes 728 Mbits/sec [ 4] local 192.168.16.11 port 5001 connected with 192.168.16.2 port 43275 [ 4] 0.0-10.0 sec 969 MBytes 811 Mbits/sec that's strange, because the other machine (with an e1000 card) has the mtu set to 7000 and i can only get a one-sided connection if i set both machines to mtu 7000: [ 5] local 192.168.16.11 port 35615 connected with 192.168.16.2 port 5001 [ 5] 0.0-10.0 sec 770 MBytes 646 Mbits/sec [ 4] local 192.168.16.11 port 5001 connected with 192.168.16.2 port 45553 (stalls) i guess i can live with setting the mtu to 7100 for the moment, thanks for the help.
gentoo-sources-2.6.20-r2 hopefully seals the deal on this. If there are MTU related problems, you might want to raise them by emailing netdev@vger.kernel.org
