On 05.11.2020 08:42, Qu Wenruo wrote: > > > On 2020/11/5 下午3:01, Heiner Kallweit wrote: >> On 05.11.2020 03:48, Qu Wenruo wrote: >>> Hi, >>> >>> Not sure if this is a regression or not, but just find out that after >>> upgrading to v5.9 kernel, one of my ethernet port on my ThinkPad T14 (ryzen >>> version) becomes very slow. >>> >>> Only *2~3* Mbps. >>> >>> The laptop has two ethernet interfaces, one needs a passive adapter, the >>> other one is a standard RJ45. >>> >>> The offending one is the one which needs the adapter (eth0). >>> While the RJ45 one is completely fine. >>> >>> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. >>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0e) >>> 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. >>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) >>> >>> The 02:00.0 one is the affected one. >>> >>> The related dmesgs are: >>> [ 38.110293] r8169 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM >>> control >>> [ 38.126069] libphy: r8169: probed >>> [ 38.126250] r8169 0000:02:00.0 eth0: RTL8168ep/8111ep, >>> 00:2b:67:b3:d9:20, XID 502, IRQ 105 >>> [ 38.126252] r8169 0000:02:00.0 eth0: jumbo features [frames: 9194 bytes, >>> tx checksumming: ko] >>> [ 38.126294] r8169 0000:05:00.0: can't disable ASPM; OS doesn't have ASPM >>> control >>> [ 38.126300] r8169 0000:05:00.0: enabling device (0000 -> 0003) >>> [ 38.139355] libphy: r8169: probed >>> [ 38.139523] r8169 0000:05:00.0 eth1: RTL8168h/8111h, 00:2b:67:b3:d9:1f, >>> XID 541, IRQ 107 >>> [ 38.139525] r8169 0000:05:00.0 eth1: jumbo features [frames: 9194 bytes, >>> tx checksumming: ko] >>> [ 42.120935] Generic FE-GE Realtek PHY r8169-200:00: attached PHY driver >>> [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE) >>> [ 42.247646] r8169 0000:02:00.0 eth0: Link is Down >>> [ 42.280799] Generic FE-GE Realtek PHY r8169-500:00: attached PHY driver >>> [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-500:00, irq=IGNORE) >>> [ 42.477616] r8169 0000:05:00.0 eth1: Link is Down >>> [ 76.479569] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow >>> control rx/tx >>> [ 91.271894] r8169 0000:02:00.0 eth0: Link is Down >>> [ 99.873390] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow >>> control rx/tx >>> [ 99.878938] r8169 0000:02:00.0 eth0: Link is Down >>> [ 102.579290] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow >>> control rx/tx >>> [ 185.086002] r8169 0000:02:00.0 eth0: Link is Down >>> [ 392.884584] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow >>> control rx/tx >>> [ 392.891208] r8169 0000:02:00.0 eth0: Link is Down >>> [ 395.889047] r8169 0000:02:00.0 eth0: Link is Up - 1Gbps/Full - flow >>> control rx/tx >>> [ 406.670738] r8169 0000:02:00.0 eth0: Link is Down >>> >>> Really nothing strange, even it negotiates to 1Gbps. >>> >>> But during iperf3, it only goes up to miserable 3Mbps. >>> >>> Is this some known bug or something special related to the passive adapter? >>> >>> Since the adapter is passive, and hasn't experience anything wrong for a >>> long time, I really doubt that. >>> >>> Thanks, >>> Qu >>> >>> >> Thanks for the report. From which kernel version did you upgrade? > > Tested back to v5.7, which still shows the miserable performance. > > So I guess it could be a faulty adapter? > >> Please test >> with the prior kernel version and report behavior (link stability and speed). >> Under 5.9, does ethtool -S eth0 report packet errors? >> > Nope, no tx/rx_errors, no missed/aborted/underrun. > > Adding that the adapter is completely passive (no chip, just converting > RJ45 pins to the I shaped pins), I'm not sure that the adapter itself > can fail. > Each additional mechanical connection may cause reflections or other signal disturbance. You could try to restrict the speed to 100Mbps via ethtool, and see what the effective speed is then. 100Mbps uses two wire pairs only.
> THanks, > Qu >
