You are not logged in.
I'm currently running kernel version 3.16.1-1. When I upgrade to 3.16.3-1, the only network interface listed is the loopback. I have two Realtek ethernet cards (though I had the same issue with just one), with the following `lspci | grep Realtek` output:
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)On my working kernel, I'm running the r8169 module. Works perfectly, with either card, or both at the same time. I tried upgrading, then using the r8168 module instead (with r8169 blacklisted) to no avail. Also have tried upgrading and leaving it alone completely, which also doesn't work. This is the output of `lsmod | grep r8` on my working system:
r8169 68119 0
mii 12675 1 r8169On my broken kernel, even with a modules-load.d file specifically instructing it to load either r8169 or r8168 and blacklist the other (in modprobe.d), it fails.
Am I missing something really dumb here? I have a feeling I am. If any other info is needed to diagnose, please just let me know. Thanks for reading.
Last edited by walternelson (2014-09-27 00:08:07)
Offline
Did the update finish correctly? Are the necessary modules in /lib/modules/[kernel version]?
Offline
I compile my own kernels (ruling out module/install issue) and can confirm 3.16.3 messes up rtl8111/8168 nics - the behaviour I get on an almost new Gigabyte motherboard with this chipset is that on *some* (but not all) switches cause it to randomly "forget" it has to talk to anything on the network. If I leave a terminal open with a constant ping going to it, no problems!
It might be unrelated... but looks a bit weird that it says advertising pause frame use, but that it's not supported? (no idea what it even means)
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
...
...
# ethtool -a eth0
Pause parameters for eth0:
Cannot get device pause settings: Operation not supportedThere's a Realtek official driver for the 8111 that's another thing to try. If I get around to fixing it today I'll let you know what it was.
Last edited by stevenhoneyman (2014-09-27 08:49:17)
My: [ GitHub | AUR Packages ]
Offline
Well, I'm glad I'm not the only one having the issue. If you do find a solution, I'd love to hear about it.
After you upgrade, is the card even listed as an interface? Post-upgrade, `ip addr` only lists a loopback device for me.
Offline
r8168 driver from Realtek fixes this (at least on the PC I had problems with)
In ethtool, 8168 drver shows connection as TP, 8169 kernel driver shows it as MII, Not sure if that's the cause or completely unrelated!
My: [ GitHub | AUR Packages ]
Offline
Interesting, after reading that, I specifically switched back to r8169 and mii and it's now working. Definitely a weird issue. Might have something to do with 3.16.4 being released as well, not sure.
Either way, thanks a lot for your input.
Offline
My story is as follows:
Recently compiled Debian kernel 3.16.2 and then had the same problem: Realtek ethernet controler for RTL8111/8168B PCI does not work anymore. Link up/down/up/down...down forever.
I verified this by creplacing cable, replacing Router port, booting windows instead of Linux, and best of all, via a BIOS check on boot up. My ASUS EVO board allows to enable a Realtek ethernet check during bootup sequence (with the not really helping result "check cable").
Download and compilation of ethernet driver for Linux from Realtek did NOT solve the issue.
What finally helped was reflasing the Mainboard BIOS (with the same version I already have had).
So it seems that the free linux driver triggers a persistent change somewhere in EEPROM and damages the Ethernet hardware.
Offline