R8168 driver causing issues

If the r8169 driver works, why do we need r8168?

Is it only for kernels <4.15 ?

R8168 does work properly on the higher kernels on some systems (except breaking on 5.1), but it has far more issues as the kernel gets newer.

1 Like

Don't forget it also depends on the chipset. There was a time when the kernel driver didn't keep up well with newer chips. This is no longer the case unless the chip was released like a month ago, but then they wouldn't be that widely used yet.

Also if we're shipping the r8168 3rd party driver, why are we not doing the same for other PCIe FE / GBE / 2.5G / Gaming Ethernet Family Controllers?

FE Ethernet LINUX driver
2.5G Ethernet LINUX driver r8125

I'm sure other external kernel modules are available as well, and not just from Realtek.

2 Likes

I think this is simply a case of sticking to what worked in the past. In the old days the r8168 driver was the reliable choice when the kernel module support was poor. Things are reversed now, the kernel module is far improved over what it once was.

I wonder whether having the r8168 driver available but not installed by default is the best approach now.

That is, new installations get the r8169 kernel driver by default, but if that doesn't work well then users can install the r8168 driver instead.

After all, if the interface is working in the live environment then why install a different driver?

2 Likes

My thoughts exactly, it's like your in my head. I wouldn't stay there long though, it gets pretty strange and scary in there. LOL :wink:

There seemed to be a lull in the r8168 issues for a few days and I thought perhaps things were settling down. Unfortunately, we're right back to multiple posts on this on a daily basis.

Welp, I should maybe consider checking if Ethernet works on my laptop (it does have a Realtek network adapter). Since I pretty much use Wi-Fi all the time on this computer, maybe Ethernet is broken and I don't even know it.

1 Like

If your on 5.0 or 5.1 and using the r8168 driver there's a good chance it's broken.

Currently, I use 4.19.

I could install Linux 5.1 (Linux 5.0 will be dead soon, so I see no point of trying on that one) to see if there is a difference on my system. If it works consistently poorly on Linux 5.1 on many systems, there is a chance that it will be trash on the next LTS kernel on which Manjaro will be based on in the future.

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

Forum kindly sponsored by