After migrating to my new desktop (Ryzen 3 3200g, MSI A320M-A PRO mobo), LAN does not connect, i.e. it is in “Wired connecting…” state after PC resumes from sleep. I need to restart. How do I debug this?
Determine when issue started, use journalctl. Look through pacman logs to see if an update may have triggered it. You may be able to downgrade, maybe not.
Try a different kernel.
Determine the exact error message from logs and your ethernet device.
Internet search / Arch Bugs search / Arch forum search … try to find someone else having the same issue.
1 Like
Thanks @otherbarry , looks like I have to dig deeper.
Hello @sanjaychak01
Could you post the output of inxi -N
@ricklinux , sorry, I had to quit debugging owing to lack of time. I have switched to Ubuntu for time being. Will come back to Endeavour as soon as the pressure is eased. Before I switched out of Endeavour, I found out the following:
-
Initially I had Endeavour with Gnome, installed on an SSD partition. On resume, the LAN would not connect.
-
I then installed Endeavour with XFCE on a HDD partition in the same machine. Surprisingly, the problem went away. LAN behaved normally on resume.
-
I then cloned that XFCE based install to the same partition in step 1 above. Remarkably enough, the problem came back!
What would the SSD have to do with LAN not working on resume? Something is running too fast perhaps for the handshake to happen on ethernet?
It’s probably not activating the ethernet when it comes out of sleep mode. If it is using the r8168 module then i would switch to the r8169 by uninstalling the r8168 package. That is why i wanted to know what the hardware is to see what chip it is using. It may be something entirely different.
@ricklinux , I still have the other partition on HDD with Endeavour. Here is inxi output:
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8168
What is the exact error message output in the logs upon resume from sleep?
journalctl journalctl -p err -b
To check from previous boot append 1 to this, to go back 2 boot cycles append 2 … and so on.
@ricklinux I tried r8169. This has a strange behaviour. It does not load on booting, so ethernet is disconnected. It randomly connects 7 min or 15 min later. dmesg confirms that. No idea why there is so much delay.
Anyway, I removed r8169, and installed r8168-dkms. That seems to have solved the problem. Resume is working now. No idea why, though.
@otherbarry in the current boot log, there was nothing relevant to network, and when I tried -1, it said no persistent log is available. 
No negative numbers, just 1 or 2 or 3 … etc.
[sanjay@dhairyam ~]$ journalctl -p err -b 1
Specifying boot ID or boot offset has no effect, no persistent journal was found.
Also, lsmod shows r8169 as well, though the package installed is r8168-dkms
[sanjay@dhairyam ~]$ lsmod | grep 816
r8168 569344 0
r8169 102400 0
mdio_devres 16384 1 r8169
libphy 151552 3 r8169,mdio_devres,realtek
[sanjay@dhairyam ~]$ sudo dmesg | grep 816
[sudo] password for sanjay:
[ 0.144316] pci 0000:25:00.0: [10ec:8168] type 00 class 0x020000
[ 0.605816] ata4: DUMMY
[ 4.641611] libphy: r8169: probed
[ 4.641785] r8169 0000:25:00.0 eth0: RTL8168h/8111h, 2c:f0:5d:78:1e:dc, XID 541, IRQ 64
[ 4.641787] r8169 0000:25:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[ 4.730773] r8169 0000:25:00.0 enp37s0: renamed from eth0
[ 4.786704] Generic FE-GE Realtek PHY r8169-2500:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-2500:00, irq=IGNORE)
[ 4.980163] r8169 0000:25:00.0 enp37s0: Link is Down
[ 7.509289] r8169 0000:25:00.0 enp37s0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 62.639608] r8169 0000:25:00.0 enp37s0: Link is Down
[ 66.454638] Generic FE-GE Realtek PHY r8169-2500:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-2500:00, irq=IGNORE)
[ 66.614892] r8169 0000:25:00.0 enp37s0: Link is Down
[ 70.371687] r8169 0000:25:00.0 enp37s0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 94.464598] r8169 0000:25:00.0 enp37s0: Link is Down
[ 95.838816] ACPI: Waking up from system sleep state S3
[ 98.301025] Generic FE-GE Realtek PHY r8169-2500:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-2500:00, irq=IGNORE)
[ 98.477773] r8169 0000:25:00.0 enp37s0: Link is Down
[ 102.148691] r8169 0000:25:00.0 enp37s0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 313.900909] r8169 0000:25:00.0 enp37s0: Link is Down
[ 317.723007] Generic FE-GE Realtek PHY r8169-2500:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-2500:00, irq=IGNORE)
[ 317.916208] r8169 0000:25:00.0 enp37s0: Link is Down
[ 322.193342] audit: type=1100 audit(1613481602.907:100): pid=3947 uid=1000 auid=1000 ses=2 msg=‘op=PAM:unix_chkpwd acct=“sanjay” exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res=success’
[ 323.272606] r8169 0000:25:00.0 enp37s0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 323.865202] audit: type=1131 audit(1613481604.582:101): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=NetworkManager-dispatcher comm=“systemd” exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success’
[ 324.878008] audit: type=1130 audit(1613481605.596:102): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=NetworkManager-dispatcher comm=“systemd” exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success’
[ 334.858447] audit: type=1131 audit(1613481615.585:103): pid=1 uid=0 auid=4294967295 ses=4294967295 msg=‘unit=NetworkManager-dispatcher comm=“systemd” exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success’
So why is the r8169 driver getting loaded, I wonder, when the package is r8168-dkms. I checked that the r8169 driver is no longer installed.
I would suggest blacklisting r8169 then as it is part of the kernel modules.
I reinstalled EOS. I find that r8169 is blacklisted, and I am having a problem with resume.
Therefore, I switched to blacklisting r8168. So r8169 has taken control, and now I do not face the problem any longer.
Thanks for your and everyone’s help!
1 Like
The r8168 is a package installed you can uninstall it actually. The r8169 is automatically loaded as a kernel module. Some Ethernet chips work better on r8168 and others on r8169. Having both sometimes interferes so that is why it is necessary to blacklist or uninstall if possible. Glad you got it figured out.
…wondering if the inclusion of r8168 package in the EOS install is solving more issues than the number of user problems caused by having it.
I think this has been brought up before. 
Yeah, I have to run this after every resume:
#!/bin/bash
sudo modprobe -r r8168 && sudo modprobe r8168
or my Asus Rog Strix laptop will not function on ethernet. It has the same chipset as yours.