R8168 driver causing issues

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?

As this thread is in Manjaro development I might suggest you open a separate thread if you need assistance with getting this adapter working. I would be more than happy to help you, but this is not really the appropriate place to troubleshoot your issue.

3 Likes

Our latest developer ISOs don't activate the r8168 driver. We still review the feedback on that change.

3 Likes

I did a fresh install of 18.0.4-stable and went for kernel 5.1

It used the r8168 by default. That driver entirely stalls after resuming from suspend, no more LAN networking and spewing kernel traces in the kernel log. Workaround is to modprobe -r and then load the module again.
There was no blacklisting set up for me under "/etc/modprobe.d/r8169_blacklist.conf"

I found this thread, removed the Realtek r8168 driver and successfully went for the kernel r8169 driver. No issues ever since.

inxi -n
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: N/A

So as I understand, the r8169 driver is by far the bette choice for recent kernels.

I did not test installing with the developer ISO. Woud that be of help for you?

1 Like

you've given the required feedback. it doesn't matter that you weren't running the dev ISO as the same thing applies. your hardware clearly works better with r8169

Testing out 18.1.0 RC5 could help in order to know (confirm) if your system will use r8169 by default instead of r8168 and if it does, if it is a real improvement (which should be, since you tested it out on your system).

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by