R8168 Trouble

General system Kernel, boot, graphics & hardware
1

So after getting the iwlwifi sorted, this lemon Asus G531GT laptop of mine has an issue with the Realtek 8168 Network card, such that after wake up it cannot send data at all;

[onyx@onyx-laptop ~]$ ping 10.0.2.254
PING 10.0.2.254 (10.0.2.254) 56(84) bytes of data.
64 bytes from 10.0.2.254: icmp_seq=1 ttl=64 time=0.443 ms
64 bytes from 10.0.2.254: icmp_seq=2 ttl=64 time=0.459 ms
64 bytes from 10.0.2.254: icmp_seq=3 ttl=64 time=0.519 ms
64 bytes from 10.0.2.254: icmp_seq=4 ttl=64 time=0.360 ms
64 bytes from 10.0.2.254: icmp_seq=5 ttl=64 time=0.490 ms
64 bytes from 10.0.2.254: icmp_seq=6 ttl=64 time=0.465 ms
64 bytes from 10.0.2.254: icmp_seq=7 ttl=64 time=0.453 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
From 10.0.2.35 icmp_seq=15 Destination Host Unreachable
From 10.0.2.35 icmp_seq=16 Destination Host Unreachable
From 10.0.2.35 icmp_seq=17 Destination Host Unreachable
From 10.0.2.35 icmp_seq=18 Destination Host Unreachable
From 10.0.2.35 icmp_seq=19 Destination Host Unreachable
From 10.0.2.35 icmp_seq=20 Destination Host Unreachable
From 10.0.2.35 icmp_seq=21 Destination Host Unreachable
From 10.0.2.35 icmp_seq=22 Destination Host Unreachable
From 10.0.2.35 icmp_seq=23 Destination Host Unreachable
^C
--- 10.0.2.254 ping statistics ---
24 packets transmitted, 7 received, +9 errors, 70.8333% packet loss, time 30738ms
rtt min/avg/max/mdev = 0.360/0.455/0.519/0.045 ms, pipe 3

Above network is unreachable whilst it wakes up, then destination host unreachable is where the network is up, but no data transferred.

FYI:

inxi -FGz
System:
  Kernel: 5.7.4-zen1-1-zen x86_64 bits: 64 Desktop: Cinnamon 4.6.4 
  Distro: EndeavourOS 
Machine:
  Type: Laptop System: ASUSTeK product: ROG Strix G531GT_G531GT v: 1.0 
  serial: <filter> 
  Mobo: ASUSTeK model: G531GT v: 1.0 serial: <filter> 
  UEFI: American Megatrends v: G531GT.306 date: 03/11/2020 
Battery:
  ID-1: BAT0 charge: 47.2 Wh condition: 47.2/50.5 Wh (93%) 
CPU:
  Topology: 6-Core model: Intel Core i7-9750H bits: 64 type: MT MCP 
  L2 cache: 12.0 MiB 
  Speed: 800 MHz min/max: 800/4500 MHz Core speeds (MHz): 1: 800 2: 800 
  3: 800 4: 800 5: 800 6: 800 7: 801 8: 801 9: 800 10: 800 11: 800 12: 800 
Graphics:
  Device-1: Intel UHD Graphics 630 driver: i915 v: kernel 
  Device-2: NVIDIA TU117M [GeForce GTX 1650 Mobile / Max-Q] driver: N/A 
  Display: x11 server: X.Org 1.20.8 driver: modesetting 
  resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 20.1.1 
Audio:
  Device-1: Intel Cannon Lake PCH cAVS driver: snd_hda_intel 
  Device-2: NVIDIA driver: snd_hda_intel 
  Sound Server: ALSA v: k5.7.4-zen1-1-zen 
Network:
  Device-1: Intel Wireless-AC 9560 [Jefferson Peak] driver: iwlwifi 
  IF: wlan0 state: up mac: <filter> 
  Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  driver: r8168 
  IF: eno2 state: up speed: 100 Mbps duplex: full mac: <filter> 
  IF-ID-1: docker0 state: down mac: <filter> 
Drives:
  Local Storage: total: 2.29 TiB used: 898.27 GiB (38.4%) 
  ID-1: /dev/nvme0n1 vendor: Intel model: SSDPEKNW512G8 size: 476.94 GiB 
  ID-2: /dev/sda vendor: Crucial model: CT2000MX500SSD1 size: 1.82 TiB 
Partition:
  ID-1: / size: 369.53 GiB used: 117.25 GiB (31.7%) fs: ext4 
  dev: /dev/nvme0n1p5 
Swap:
  Alert: No Swap data was found. 
Sensors:
  System Temperatures: cpu: 49.0 C mobo: N/A 
  Fan Speeds (RPM): cpu: 3000 
Info:
  Processes: 327 Uptime: 6m Memory: 31.21 GiB used: 2.47 GiB (7.9%) 
  Shell: bash inxi: 3.1.03 


dmesg | grep 8168
[    0.448025] pci 0000:03:00.0: [10ec:8168] type 00 class 0x020000
[    2.731108] r8168 Gigabit Ethernet driver 8.048.02-NAPI loaded
[    2.747946] r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[    2.749992] r8168  Copyright (C) 2020  Realtek NIC software team <nicfae@realtek.com> 
[    2.761452] Modules linked in: i2c_algo_bit pcc_cpufreq(-) intel_uncore acpi_cpufreq(-) snd r8168(OE) iwlwifi(+) drm_kms_helper input_leds soundcore intel_lpss_pci(+) pcspkr intel_rapl_perf i2c_i801 ofpart cmdlinepart intel_spi_pci intel_spi spi_nor processor_thermal_device intel_rapl_common intel_soc_dts_iosf mtd tpm_crb cec mei_me rc_core mei intel_gtt syscopyarea sysfillrect sysimgblt fb_sys_fops cfg80211 tpm_tis intel_lpss rfkill idma64 intel_pch_thermal tpm_tis_core i2c_hid tpm int3403_thermal int3400_thermal hid int340x_thermal_zone acpi_thermal_rel wmi mac_hid asus_wireless rng_core evdev ac battery acpi_tad vboxnetflt(OE) vboxnetadp(OE) vboxdrv(OE) coretemp msr pkcs8_key_parser sg crypto_user drm agpgart ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 serio_raw atkbd libps2 crc32c_intel xhci_pci xhci_hcd i8042 serio
[    2.952357] r8168 0000:03:00.0 eno2: renamed from eth0
[   10.264233] r8168: eno2: link up
[   50.779729] r8168: eno2: link up
2

I used to have issues with the r8168 driver when resuming from standby, disabling and reenabling the driver was usually enough to fix the issue.
I used this line added to my .aliases file for manually resetting the adapter:

alias netup="sudo modprobe -r r8168 && sudo modprobe r8168"

This is a manual approach, but I remember I also created some scripts to do this automatically on resume. Can’t remember the details but if the manual command above helps, then figuring out how to automatize this should not be too difficult.

2 Likes
3

Nice one, thanks @nate!

4

You could also try the the r8169 driver. It has worked for some. Have a look at this info (#10) it may be of interest.

https://forum.manjaro.org/t/solved-several-issues-since-may-26th-update/89647/9

1 Like
5

i really not sure why Endeavour OS had to result to installing this driver. i never needed this on any other arch installers including vanilla one. I tested the latest ISO which had the driver already installed, fixed my standing issue during install. BUT i had to remove this driver and let arch use its 8169 driver after all was installed coz my connection was dropping. Im having connection problems with wlan 8188eu but that might be a general arch problem (im yet to test vanilla arch).

6

Certain hardware chips use r8169 others use r8168 Sometimes there are problems with the r8169. Sometimes there are issues on either. It depends on the hardware and vendor. There have been more issues with the r8169 that i have seen here.

7

I remember when I had the issues I described above I had to remove the r8169 drivers as my NIC wouldn’t run at all with it.

8

Sorry to drag out this old thread again. I have the 8168 chip installed, constantly use the latest LTS kernel. Now it is so that with the latest kernel the Ethernet driver jumps by itself to the r8169, but with the LTS kernel only works if I uninstall the r8168er via the Welcome app. But if I additionally install the r8168-lts driver, it runs on r8168 again. My question now: which is better, to use the r8160-lts or to go straight to the r8169? I know, I have asked a similar question at some point, but then I was recommended the r8168-dkms from the AUR, which I do not really like (in terms of such important things, like drivers!).

9

I guess you simply have to test which driver is best for that system.

Install packages r8168 and r8168-lts, reboot, and test with both (or all of your) kernels.
If any kernel fails, then uninstall packages r8168 and r8168-lts, reboot, and test again.
If you use other kernels, then r8168-dkms seems to be the only alternative to test.

I have a machine that has 8168 chip too. And based on my previous tests I thought it works with either of the drivers, 8168 or 8169.

But just yesterday I noticed (for the first time) that with the LTS kernel the same machine works only with the 8169 driver.

So I removed the r8168 package, and now the machine works with both kernels (linux and linux-lts).

1 Like
10

Out of curiosity, could you show the result of command:

  lspci -vnn | sed -n '/Ethernet controller/,/^$/p'
11 
[uwe@HAL ~]$ lspci -vnn | sed -n '/Ethernet controller/,/^$/p'
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards [1043:8432]
Flags: bus master, fast devsel, latency 0, IRQ 18
I/O ports at d000 [size=256]
Memory at d0304000 (64-bit, prefetchable) [size=4K]
Memory at d0300000 (64-bit, prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: r8169
Kernel modules: r8169
12

That’s the curious thing: It works with both solutions. If r8168 is only na to enable an internet connection initially (as I gathered from the previous thread), then it is probably unnecessary once r8169 has taken over by itself. BUT: both work (r8169 and r8168/r8168-lts, only not r8168 standalone). Which is to be preferred???

13

When you are in the lts kernel though r8169 doesn’t work for it correct?

15

indeed, so it is. then the Ethernet connection is not present.
only when the r8168 has been uninstalled and thus r8169 takes over, it works again. But SAME result, if instead still r8168-lts comes in addition to the existing r8168.

1 Like
16

So… does 8169 driver work with all kernels? If so, then you can uninstall all r8168 based packages (r8168*) permanently.

1 Like
17

thanks @manuel :+1:t2:

1 Like
18

This is what i was wanting know because i didn’t think the r8169 did? Never tried it on lts on mine.

19

@ricklinux the LTS works, but I have now also completely abandoned it and let the r8169 work.

20

I knew the r8168-lts works. I was just wondering if the r8169 worked on both kernels. But i guess you are saying it does. :+1:

21

yes, but only if the r8168 has been removed!

1 Like