Latest working kernel version: N/A Earliest failing kernel version: 2.6.27 (tried also 2.6.26) Distribution: Gentoo Linux (tried also Ubuntu & SuSE) Hardware Environment: Geode LX 800 1GB Memory 320GB HDD Dual Realtek RTL8110SC/RTL8169SC Gigabit Onboard Problem Description: Well there is a strange problem :( If i want to use the r8169 under linux, the performance is very slow. samba, ftp, nfs, wget. Every service gives about ~ 2mb/s maximum. I am not able to get faster speeds. If i am install Windows XP, every problem goes away. I am getting here about ~ 11mb/s on 100mbit mode. So what could be the problem? Steps to reproduce: Install a Distribution and Play with r8169
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded r8169 0000:00:0c.0: PCI INT A -> Link[LNKC] -> GSI 10 (level, low) -> IRQ 10 eth0: RTL8169sc/8110sc at 0xf0006000, 00:0f:c9:03:5e:52, XID 18000000 IRQ 10 r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded r8169 0000:00:0d.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11 eth1: RTL8169sc/8110sc at 0xf000e000, 00:0f:c9:03:5e:53, XID 18000000 IRQ 11
Are you using mainline 2.6.26/27 kernels or vendor ones ? Please send a complete dmesg + lspci -vvxxx -- Ueimor
Hello! I tried Kernel 2.6.26/27 directly from kernel.org AND the "gentoo-specific" sources. Both gave me the same results. Attaching also dmesg.log and lspci.log
Created attachment 18310 [details] /bin/dmesg output
Created attachment 18311 [details] /usr/sbin/lspci -vvxxx output
Comment #4 from ConiKost@gmx.de 2008-10-14 12:32 : > Created an attachment (id=18310) > --> (http://bugzilla.kernel.org/attachment.cgi?id=18310&action=view) > /bin/dmesg output Something is wrong with your setup: Linux version 2.6.27 (root@Bl4ckB0x) (gcc v... [...] r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded ^^^ should be 2.3LK-NAPI Can you try 2.6.27 with its native 2.3LK-NAPI driver ?
Argh, i am sorry. I uploaded wrong copy of dmesg.log This is now the right log.
Created attachment 18314 [details] /bin/dmesg output
The IRQ line of one of your ethernet devices is hevily shared. Do both ethernet devices behave the same ?
No, eth0 and eth1 (both are r8169) got different IRQs. Here is my /proc/interrupts Bl4ckB0x / # cat /proc/interrupts CPU0 0: 12361218 XT-PIC-XT timer 2: 0 XT-PIC-XT cascade 3: 77 XT-PIC-XT serial 4: 76338 XT-PIC-XT serial 5: 0 XT-PIC-XT CS5535 Audio 7: 2 XT-PIC-XT parport0 9: 0 XT-PIC-XT acpi 10: 7172581 XT-PIC-XT eth0 11: 6234945 XT-PIC-XT ehci_hcd:usb1, ohci_hcd:usb2, eth1 14: 150790 XT-PIC-XT pata_cs5536 NMI: 0 Non-maskable interrupts ERR: 0 As you see, eth0 has its own, eth1 shared with usb. No usb device is plugged in.
Comment #10 from ConiKost@gmx.de 2008-10-14 14:09 : > No, eth0 and eth1 (both are r8169) got different IRQs. Ok. And both devices are slow, right ?
(In reply to comment #11) > Comment #10 from ConiKost@gmx.de 2008-10-14 14:09 : > > No, eth0 and eth1 (both are r8169) got different IRQs. > > Ok. And both devices are slow, right ? > Yep, you are right. Both are slow.
ConiKost@gmx.de 2008-10-14 14:16 : [...] > Yep, you are right. Both are slow. Can you try a simple 'mii-tool -R eth0' (resp. eth1) and wait a few seconds ? It smells like PHY.
(In reply to comment #13) > ConiKost@gmx.de 2008-10-14 14:16 : > [...] > > Yep, you are right. Both are slow. > > Can you try a simple 'mii-tool -R eth0' (resp. eth1) and wait a few > seconds ? > > It smells like PHY. > So, well ... there seems to be problem. 'mii-tool -R eth0' works fine. After a few seconds, the link comes back again. But speed ist still slow. 'mii-tool -R eth1' do not work. After execute, the link goes down and stays down. the complete interface is just offline. no lights blinking. i need to shut down the whole system and reboot. This is only the thing, which brings eth1 back online.
Any suggestion?
Created attachment 18386 [details] PHY init for the 8169scd Can you give the attached patch a try ? -- Ueimor
Patch didn't help. 'mii-tool -R eth1' still does not work.
How is this tested? I have noticed an interesting problem that fits this description. - works OK with Windows, much slower in Linux I think the cause is this: * The input is artificially bandwidth limited, strange things happens. Some ISPs sells differented levels of services with the same hardware. Suppose your hardware premits 10Mb/s the ISP can sell 2Mb/s, 5Mb/s, 8Mb/s by letting the server or router add artificial delays to trottle the bandwith to the agreed level. This works fine with Windows. But I think Linux follows RFCs more strictly... Maybe it is not Linux that is at fault but a switch/router? (But Linux should really handle this situation too)
I also have this same problem. I'm running Gentoo, vanilla-sources, tried 2.6.26 and 2.6.28. With a default TCP/IP configuration I get single digit Mbit/s. With speed tweaks I can get up in the range of 100Mbits/sec. If it would be of use I can post my details as well.
I think there is an issue with r8169 drivers. I moved from 2.6.22 to 2.6.28 and then to 2.6.31 (just to eliminate 2.6.28). The performance from r8169 drivers is horrible. What used to take 2mins to download something from the internet now takes about 30-40 mins (I have a script which calls about 100 wgets to same site). If I switch to 2.6.22 kernel, the script finishes in less than 2 mins. With 2.6.31 kernel, it takes about 30-40mins. This is unacceptable. Please can someone look at this issue.
Mudit, you should identify which kernel (or better : which commit) added the regression. Btw a complete dmesg with 2.6.31 would be welcome to identify your hardware. -- Ueimor
I get almost exactly 1 megabyte per second transfer rate across my wired 100 mbit LAN. Other devices on the LAN get much higher rates. I'm using Ubuntu with kernel 2.6.31. Here's lspci: 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) Here's dmesg: [ 2.615233] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 2.615249] r8169 0000:03:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 2.615279] r8169 0000:03:00.0: setting latency timer to 64 [ 2.615309] alloc irq_desc for 28 on node -1 [ 2.615311] alloc kstat_irqs on node -1 [ 2.615321] r8169 0000:03:00.0: irq 28 for MSI/MSI-X [ 2.615785] eth0: RTL8168d/8111d at 0xf82ce000, 00:24:1d:18:f9:ea, XID 281000c0 IRQ 28 My motherboard is a GIGABYTE GA-MA790XT-UD4P AM3 DDR3 AMD (790X ATX AMD chipset)
This is same as Bug 14069 I have two machines with onboard 8111/8168. One of them is Win7/XP and another is Fedora14/XP dual boot. Under WinXP or Win7 xfer rate between the machines is limited with only their HDD read speed (using copy...nul) and reaches 100 MB/s. Under Fedora 14 xfer speed is ranging from 7.5 to 9.5 MB/s depending on god knows what. I reported under Bug 14069 that driver can't be switched to gigabit mode using ethtool. Please someone look at this driver - RT8168 is the most common network chip on AMD platform, this is affecting half of the Linux users worldwide.
Is this driver supported by its developer at all? How come there is plenty gigabit and 10gig drivers in the kernel that perform satisfactorily, but not the driver for the most widespread NIC chip in the world? Open source community should be able to identify problematic pieces of code and find volunteers willing to fix the problem if the original author is not able to do anything about it for 5 straight years. This is ridiculous and reflects badly on Linux. I am unimpressed.
If this is still seen on modern kernels then please re-open/update
+1 I just tried my Realtek network card in a lenovo g550 laptop with the r8169 driver and have the same problem. only close to 2Mbit/sec. Kernel is 3.2.54-2 debian backports oldstable.