Ethernet fails to initialize
Solution 1
I got the same error and resolve this by reloading driver for network device. First need to find appropriate pci device:
find /sys/devices -name enp3s0
I got /sys/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/net/enp3s0
. Then remove pci device and rescan bus:
echo 1 >/sys/devices/pci0000:00/0000:00:1c.2/0000:03:00.0/remove
echo 1 >/sys/devices/pci0000:00/0000:00:1c.2/rescan
Done, network interface reinitialized.
I got the next kernel log:
Apr 17 12:43:55 host kernel: r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1 (loop: 1000, delay: 10).
Apr 17 12:43:55 host kernel: r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1 (loop: 1000, delay: 10).
Apr 17 12:43:55 host kernel: r8169 0000:03:00.0 (unregistered net_device): rtl_counters_cond == 1 (loop: 1000, delay: 10).
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: [10ec:8168] type 00 class 0x020000
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: reg 0x10: [io 0x0000-0x00ff]
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: reg 0x18: [mem 0x00000000-0x00000fff 64bit]
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref]
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: supports D1 D2
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: System wakeup disabled by ACPI
Apr 17 12:44:28 host kernel: i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: BAR 4: assigned [mem 0xf0100000-0xf0103fff 64bit pref]
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: BAR 2: assigned [mem 0xf7d00000-0xf7d00fff 64bit]
Apr 17 12:44:28 host kernel: pci 0000:03:00.0: BAR 0: assigned [io 0xe000-0xe0ff]
Apr 17 12:44:28 host kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Apr 17 12:44:28 host kernel: r8169 0000:03:00.0: irq 29 for MSI/MSI-X
Apr 17 12:44:28 host kernel: r8169 0000:03:00.0 eth0: RTL8168g/8111g at 0xffffc90007ce2000, 80:ee:73:xx:xx:xx, XID 0c000800 IRQ 29
Apr 17 12:44:28 host kernel: r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
Apr 17 12:44:28 host kernel: IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
Apr 17 12:44:28 host kernel: r8169 0000:03:00.0 enp3s0: link down
Apr 17 12:44:28 host kernel: r8169 0000:03:00.0 enp3s0: link down
Apr 17 12:44:28 host kernel: IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
Apr 17 12:44:31 host kernel: r8169 0000:03:00.0 enp3s0: link up
Apr 17 12:44:31 host kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
In other way you can try to reload driver itself, like this: rmmod r8169; modprobe r8169
. I didn't try this because I have the second similar network device used me to ssh.
Solution 2
Had this problem with an ethernet that wasn't connected generating log spam of the same type mentioned by the OP.
The method fixed this. Here's a quick script to do this as gratitude for the fix. :)
#!/bin/bash
DEVICE=$(find /sys/devices -name $1|sed -e 's/\/net\/.*//')
[ -z "$DEVICE" ] && echo "There doesn't seem to be a device $1" && exit 2
echo "Removing device at $DEVICE"
echo 1 > $DEVICE/remove
sleep 2
DEVICE_RESTART=$(dirname $DEVICE)
echo "Rescanning $DEVICE_RESTART"
echo 1 > $DEVICE_RESTART/rescan
Here it is in use:
sbicknel@bick-ubtu2:~$ /tmp/restart_ethernet enp2s0
There doesn't seem to be a device enp2s0
sbicknel@bick-ubtu2:~$ sudo /tmp/restart_ethernet enp5s0
Removing device at /sys/devices/pci0000:00/0000:00:1c.5/0000:05:00.0
Rescanning /sys/devices/pci0000:00/0000:00:1c.5
sbicknel@bick-ubtu2:~$
Related videos on Youtube
nakala
Updated on September 18, 2022Comments
-
nakala over 1 year
I have a problem with my ethernet. it is unable to connect. From other answers on this site, i have the following messages.
lspci -nn | grep 0200
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136] (rev 07)
sudo modprobe r8101
modprobe: FATAL: Module r8101 not found in directory /lib/modules/4.4.0-72-generic
dmesg | grep -e eth
[ 2.078821] r8169 0000:03:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [ 2.078853] r8169 0000:03:00.0 eth0: RTL8101e at 0xf841a000, ff:ff:ff:ff:ff:ff, XID 9cf0f8ff IRQ 89 [ 2.173432] r8169 0000:03:00.0 enp3s0: renamed from eth0
dmesg | grep -e eth -e r8169
[ 2.022696] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded [ 2.022711] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 2.022824] r8169 0000:03:00.0 (unnamed net_device) (uninitialized): unknown MAC, using family default [ 2.032807] r8169 0000:03:00.0 (unnamed net_device) (uninitialized): rtl_chipcmd_cond == 1 (loop: 100, delay: 100). [ 2.078821] r8169 0000:03:00.0 eth0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [ 2.078853] r8169 0000:03:00.0 eth0: RTL8101e at 0xf841a000, ff:ff:ff:ff:ff:ff, XID 9cf0f8ff IRQ 89 [ 2.173432] r8169 0000:03:00.0 enp3s0: renamed from eth0 [ 2.195505] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [ 242.859397] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1 (loop: 1000, delay: 10). [ 245.874622] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1 (loop: 1000, delay: 10).
The rtl_counters_cond seems to be repeated every few seconds or minutes and goes on for tens of lines in the output. i have truncated it.
Help please.
-
nakala almost 6 yearsHey, this did not work for me
-
Stephen Rauch almost 6 yearsHow does this differ from the previous answers?
-
maectpo about 5 yearsDo you know why is it happening? Can I find and fix root cause of the problem?
-
SergA about 5 years@maectpo I don't know the root of the problem. But I notice that this happens when there is 200Mbps and more traffic (mostly multicasts) in my segment.
-
nakala almost 5 yearsI sold off the laptop with this problem so I cannot test out the script. Thank you though and I hope others find it useful.
-
Pau Coma Ramirez about 3 yearsI did
sudo modprobe -r r8169
,sudo modprobe r8169
, driver unloaded and loaded but problem persisted. System Restart afterwards and it was gone.. probably was missing some kind of re-inicialization within my routine.