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
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
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
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.
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.
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?