Fedora 40 - r8169 issues maybe

Ask Fedora
, ,
1

I just did a clean install of Fedora 40 on a ThinkCenter M715q. The NIC is not acting right. If I start a ping to my gateway everything looks good. If I open up a browser or any app that tries to reach out to the internet, ping times go up high and bottlenecks the connection. Ping window below, you can see where pings are low, start up my app, ping times go high, close my app, ping times go low again. I have tried turning off “eee”, blacklisting 8169 driver and install the dkms-r8168 driver, and also reverted from the latest updated kernel 6.11 to 6.8 and doesnt work.
I have swapped cables, swapped switch interfaces, set static 1000/full. There are no errors on the interfaces.

Any advice is appreciated.

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 0e)
	Subsystem: Lenovo Device 3130
	Kernel driver in use: r8169
	Kernel modules: r8169

 lsmod | grep r8169
r8169                 114688  0

[    2.464403] r8169 0000:01:00.0 eth0: RTL8168ep/8111ep, 6c:4b:90:bc:f6:9c, XID 502, IRQ 52
[    2.464414] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    2.464419] r8169 0000:01:00.0 eth0: DASH disabled
[    2.494008] r8169 0000:01:00.0 enp1s0f0: renamed from eth0
[    9.387587] Generic FE-GE Realtek PHY r8169-0-100:00: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC)
[    9.467863] r8169 0000:01:00.0 enp1s0f0: Link is Down
[   12.070243] r8169 0000:01:00.0 enp1s0f0: Link is Up - 1Gbps/Full - flow control rx/tx
[    2.494008] r8169 0000:01:00.0 enp1s0f0: renamed from eth0
[    9.467863] r8169 0000:01:00.0 enp1s0f0: Link is Down
[   12.070243] r8169 0000:01:00.0 enp1s0f0: Link is Up - 1Gbps/Full - flow control rx/tx


4 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.156 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.171 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.137 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.147 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=816 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1595 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=2896 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=3942 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=3935 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=4276 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=4370 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=4644 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=4283 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=4349 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=3683 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=2850 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=1950 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=1218 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=353 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=0.174 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=0.167 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=0.173 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=0.186 ms
2

Just an update, I also tried installing from Realtek’s driver repo directly with 8168 and still the same issue.

3

Added networking, realtek

4

Are you sure your chipset is r8169? I am asking because it doesn’t list that device in the controller’s description: “RTL8111/8168/8211/8411”. From log: “r8169 0000:01:00.0 eth0: RTL8168ep/8111ep”.

Also, you are writing you used the 8168 from Realtek, that’s a different one…

can you show us the output of inxi -Fz and/or potentially inxi -Faz?

You may also want to check this forum for previous posts about the chip (after confirming the model): Search results for 'r8169' - Fedora Discussion, e.g. RTL8111/8168/8411 Realtek Ethernet controller not working - r8169 related - #8 by overmach

5

Yea I saw that. And yes I used the link you sent. It didnt make a difference. Going to try to find this “ep” version.

6

So one thing I did find is that in the RealTek site it says their driver for “EP” version is only available up to kernel 6.8. So I will see if installing this under kernel 6.8 works.

1 Like
7

@augenauf here is that output…

Network:
Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: Lenovo driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1
port: f000 bus-ID: 01:00.0 chip-ID: 10ec:8168 class-ID: 0200
IF: enp1s0f0 state: up speed: 1000 Mbps duplex: full mac:

8

No luck with 6.8. Per the Realtek website on this “ep” version, seems to be a fancy pants NIC using USB over PCIe and this DASH setup for mgmt. I remembered seeing DASH settings in the BIOS. It was disabled. So I just enabled DASH in the Lenovo BIOS. So far the NIC seems to be working normal under the 8169 driver that comes default. I will keep an eye on it and see if it hiccups. Not sure what this DASH is controlling in the BIOS but hopefully this will help.

1 Like
9

The r8169 module appears to support your device:

% modinfo r8169 
filename:       /lib/modules/6.11.5-300.fc41.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
firmware:       rtl_nic/rtl8126a-2.fw
[...]
license:        GPL
softdep:        pre: realtek
description:    RealTek RTL-8169 Gigabit Ethernet driver
author:         Realtek and the Linux r8169 crew <netdev@vger.kernel.org>
author:         Realtek and the Linux r8169 crew <netdev@vger.kernel.org>
[...]
alias:          pci:v000010ECd00008168sv*sd*bc*sc*i*
[...]

Linux Hardware Database probes for “RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller” give PCI:10ec-8168-10ec-0123 with mixed results for many different linux distros/versions and mention an alternate driver from https://github.com/mtorromeo/r8168.

1 Like
10

Yea it supports it. Since Ive enabled DASH in the BIOS, I havent had any issues all day today. There was nothing to enabling DASH, just enable or disable. And DASH is for remote mgmt so I’m not real sure what thats all about and why it needs to be enabled for the NIC to work correctly. I’m gonna mark this issue closed. Thanks everyone for the help.