R8168 driver causing issues

It's possible the correct extramodule has been added to 5.1 now and it may be working properly for you. I'm not sure about that, all I know is the help requests are still hot'n heavy on a daily basis.

And yet the built in kernel module is faster and more stable, than the third party crap from Realtek..
The only real reason for even having the 8168 driver available is if your chip is so new, that the 8169 driver doesn't support it at all.

Welp, here's the results of my quick tests.

My Ethernet adapter works fine with both r8168 and r8169 modules, and on Linux 5.1.1, 5.0.15 and Linux 4.19.42. I see no noticeable difference at first glance. No driver failed on any kernel version I tried out.

However, I only tested if I have access to my LAN and Internet; I did not benchmark the download speed and upload speed in each case. It would have taken too much time for me to do so.

Conclusion: On my laptop, using r8168 and r8169 doesn't make anything better or worse. Therefore, switching to r8169 as the default would not make much a difference for me.

The fact that my laptop is slightly old (around 2 years and a half) might help.

Here's a complete inxi -Fxxxn so you can have a detailed profile of my machine.

System:
  Host: ideapad Kernel: 5.1.1-2-MANJARO x86_64 bits: 64 compiler: gcc 
  v: 8.3.0 Desktop: Cinnamon 4.0.10 dm: LightDM 1.28.0 Distro: Manjaro Linux 
Machine:
  Type: Laptop System: LENOVO product: 80SM v: Lenovo ideapad 310-15ISK 
  serial: <root required> Chassis: type: 10 v: Lenovo ideapad 310-15ISK 
  serial: <root required> 
  Mobo: LENOVO model: Toronto 5A2 v: SDK0J40700 WIN serial: <root required> 
  UEFI: LENOVO v: 0XCN36WW date: 08/30/2016 
Battery:
  ID-1: BAT0 charge: 16.9 Wh condition: 28.9/30.0 Wh (96%) volts: 7.3/7.3 
  model: SANYO L15S2TB0 type: Li-ion serial:  2022 status: Discharging 
CPU:
  Topology: Dual Core model: Intel Core i5-6200U bits: 64 type: MT MCP 
  arch: Skylake rev: 3 L2 cache: 3072 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 19204 
  Speed: 565 MHz min/max: 400/2800 MHz Core speeds (MHz): 1: 600 2: 600 
  3: 601 4: 604 
Graphics:
  Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: Lenovo driver: i915 
  v: kernel bus ID: 00:02.0 chip ID: 8086:1916 
  Display: x11 server: X.Org 1.20.4 driver: modesetting 
  alternate: fbdev,intel,vesa tty: N/A 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 520 (Skylake GT2) 
  v: 4.5 Mesa 19.0.4 compat-v: 3.0 direct render: Yes 
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio vendor: Lenovo 
  driver: snd_hda_intel v: kernel bus ID: 00:1f.3 chip ID: 8086:9d70 
  Sound Server: ALSA v: k5.1.1-2-MANJARO 
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: Lenovo driver: r8168 v: 8.047.01-NAPI port: 3000 bus ID: 01:00.0 
  chip ID: 10ec:8168 
  IF: enp1s0 state: up speed: 1000 Mbps duplex: full mac: c8:5b:76:55:9e:e4 
  Device-2: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter 
  vendor: Lenovo driver: ath10k_pci v: kernel port: 3000 bus ID: 02:00.0 
  chip ID: 168c:0042 
  IF: wlp2s0 state: down mac: 9a:46:27:14:ef:c5 
  Device-3: Qualcomm Atheros type: USB driver: btusb bus ID: 1-7:5 
  chip ID: 0cf3:e360 
Drives:
  Local Storage: total: 931.51 GiB used: 17.14 GiB (1.8%) 
  ID-1: /dev/sda vendor: Western Digital model: WD10JPCX-24UE4T0 
  size: 931.51 GiB speed: 6.0 Gb/s rotation: 5400 rpm 
  serial: WD-WXR1EB544K0D rev: 1A01 scheme: GPT 
Partition:
  ID-1: / size: 140.67 GiB used: 17.12 GiB (12.2%) fs: ext4 dev: /dev/sda4 
  ID-2: swap-1 size: 1.95 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda7 
Sensors:
  System Temperatures: cpu: 30.5 C mobo: N/A 
  Fan Speeds (RPM): N/A 
Info:
  Processes: 181 Uptime: 3m Memory: 7.70 GiB used: 1.10 GiB (14.3%) 
  Init: systemd v: 242 Compilers: gcc: 8.3.0 clang: 8.0.0 Shell: bash 
  v: 5.0.7 running in: gnome-terminal inxi: 3.0.34  

And pacman -Q | grep linux. (Note that this computer is on Testing branch.)

linux-api-headers 5.0.7-1
linux-firmware 20190424.4b6cf2b-1
linux419 4.19.42-1
linux419-r8168 8.047.01-1
linux50 5.0.15-1
linux50-r8168 8.047.01-1
linux51 5.1.1-2
linux51-r8168 8.047.01-1
1 Like

Yes, however, using the kernels own driver instead of a third party external module also reduces, or in my case eliminates, those pesky irrelevant acpi kernel messages on boot, that we typically get to explain, over, and over, and over, and over, and. Well, you get the idea.

Another serious issue with r8168.

Another recent Realtek related problem solved by ditching out r8168 and go on r8169.

Welp. Looks like r8168 is now a bit a pain in the a- currently, I don't recall seeing so much issues like this in the past. The more time goes on, the more switching to r8169 as the default seems to make sense and be the right move.

EDIT: Well, maybe it was not that simple. There had been a pretty messy development in the original thread after I linked it here.

I have found that changing the blacklist from 8169 to 8168 solves ny issues on my clevo system.

modprobe -r r8168
modprobe r8169

Wouldn't just removing Realtek's third party driver make whole lot more sense than editing system files? sudo pacman -R linux###-r8168

you still have to change the blacklist from 8169 to 8168

Well, If I'm not mistaken, MHWD is what adds that blacklist file.
So, instead of pacman, use mhwd to remove the r8168 driver then.

$ sudo mhwd -r pci network-r8168

I could be wrong, but I'm pretty sure it works ilike this:

I never advise removing via pacman, but I believe the blacklist remains if pacman is used.

If you remove the r8168 driver via mhwd the blacklist remains.

If you remove the driver through MSM the blacklist is normally removed (but in rare cases it's not).

It does; I removed r8168 from a laptop recently (with pacman) and found I couldn't load r8169 because the blacklist was still in place.

1 Like

Hmm, now that just doesn't make sense.
Doesn't msm use mhwd in the background?

Ya I know it doesn't make sense, but that has been what I have noticed when the terminal method was used. I'm pretty sure I have to walk people through a manual clean up of the blacklist files.

Even stranger I have found instances of blacklist files being created in /usr/lib/modprobe.d/ in a couple of cases.

That does the trick - never thought of using mhwd to do it.

MHWD uses pacman to remove the package linuxXXX-r8168 so I wonder why the PKGBUILD does not contain the code to maintain the blacklist.

I am checking if the blacklist of r8168 is really necessary when the module has been removed with MHWD

It's probably because the blacklist file could be in use by multiple packages (i.e. one for each kernel version).

There's probably some logic that could be used to detect whether that package was the last one to use the blacklist file, and if so remove it.

Or, install a blacklist file for each kernel version package. Multiple files won't get in the way of each other.

We can try in our current development cycle to remove r8168 driver to be shipped with our ISOs. Most likely the internal drivers should work.

1 Like

Will it still install the r8168 driver on the new system when you do the OS installation though?

Hi! I have problems with r8169 kernel module in kernel versions 5.0 and 5.1.

lsmod | grep r81
r8169 90112 0
libphy 90112 3 r8169,realtek

dmesg | grep eno1
[ 4.301164] r8169 0000:3b:00.0 eno1: renamed from eth0
[ 5.055202] r8169 0000:3b:00.0 eno1: Link is Down
[ 18.913811] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 19.371564] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[ 20.325957] r8169 0000:3b:00.0 eno1: Link is Down
[ 34.134927] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 34.138310] r8169 0000:3b:00.0 eno1: Link is Down
[ 48.623278] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 48.630662] r8169 0000:3b:00.0 eno1: Link is Down
[ 62.464262] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 62.467556] r8169 0000:3b:00.0 eno1: Link is Down
[ 76.984971] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 76.987948] r8169 0000:3b:00.0 eno1: Link is Down
[ 91.723753] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 91.728137] r8169 0000:3b:00.0 eno1: Link is Down
[ 105.538914] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 105.542402] r8169 0000:3b:00.0 eno1: Link is Down
[ 120.218961] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 120.221989] r8169 0000:3b:00.0 eno1: Link is Down
[ 134.739637] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 134.742736] r8169 0000:3b:00.0 eno1: Link is Down
[ 148.697050] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 148.700802] r8169 0000:3b:00.0 eno1: Link is Down
[ 162.497525] r8169 0000:3b:00.0 eno1: Link is Up - 100Mbps/Full - flow control rx/tx
[ 162.500578] r8169 0000:3b:00.0 eno1: Link is Down

Constantly ... and with the r8168 from the manjaro repo's the problem is bigger because it does not try to link / up the connection (if I use Live USB, works fine).

Interesting. So neither driver supports your hardware?

Have you found any references to this or similar issues anywhere else?

Forum kindly sponsored by