Ethernet doesn't work after a suspension/powering on.

After a suspension or powering on I don't have access to the internet. My computer tells me that the cable is disconnected, which is a lie because it's always plugged in. I don't know the cause of this problem because this issue appears quite randomly. Sometimes everything works just fine, sometimes it does not. Also I'm quite frustrated, because reboot doesn't work, as well as connecting and disconnecting the cable. Problem appears on multiply cables and only after suspension/powering on.

System:    Host: marcin-pc Kernel: 5.4.6-2-MANJARO x86_64 bits: 64 compiler: gcc v: 9.2.0 Desktop: Gnome 3.34.2 
           wm: gnome-shell dm: GDM 3.34.1 Distro: Manjaro Linux 
Machine:   Type: Desktop System: ASUS product: All Series v: N/A serial: <filter> 
           Mobo: ASUSTeK model: Z97-PRO GAMER v: Rev X.0x serial: <filter> UEFI [Legacy]: American Megatrends 
           v: 2203 date: 02/26/2016 
CPU:       Topology: Quad Core model: Intel Core i7-4790K bits: 64 type: MT MCP arch: Haswell rev: 3 
           L2 cache: 8192 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 64031 
           Speed: 1100 MHz min/max: 800/4400 MHz Core speeds (MHz): 1: 1059 2: 1047 3: 1045 4: 1057 5: 1095 6: 1093 
           7: 1095 8: 1030 
Graphics:  Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: Micro-Star MSI driver: nvidia v: 440.44 bus ID: 01:00.0 
           chip ID: 10de:13c2 
           Display: x11 server: X.org 1.20.6 driver: nvidia compositor: gnome-shell resolution: <xdpyinfo missing> 
           OpenGL: renderer: GeForce GTX 970/PCIe/SSE2 v: 4.6.0 NVIDIA 440.44 direct render: Yes 
Audio:     Device-1: Intel 9 Series Family HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 00:1b.0 
           chip ID: 8086:8ca0 
           Device-2: NVIDIA GM204 High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel 
           bus ID: 01:00.1 chip ID: 10de:0fbb 
           Device-3: C-Media Multimedia Headset [Gigaware by Ignition L.P.] type: USB 
           driver: hid-generic,snd-usb-audio,usbhid bus ID: 2-13:5 chip ID: 0d8c:0139 
           Sound Server: ALSA v: k5.4.6-2-MANJARO 
Network:   Device-1: Intel Ethernet I218-V vendor: ASUSTeK driver: e1000e v: 3.2.6-k port: f040 bus ID: 00:19.0 
           chip ID: 8086:15a1 
           IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 236.00 GiB used: 145.52 GiB (61.7%) 
           ID-1: /dev/sda vendor: Intenso model: SSD Sata III size: 236.00 GiB speed: 6.0 Gb/s serial: <filter> 
           rev: 6K scheme: MBR 
Partition: ID-1: / size: 231.30 GiB used: 145.52 GiB (62.9%) fs: ext4 dev: /dev/sda1 
Sensors:   System Temperatures: cpu: 29.8 C mobo: 27.8 C gpu: nvidia temp: 44 C 
           Fan Speeds (RPM): N/A gpu: nvidia fan: 0% 
Info:      Processes: 247 Uptime: 4h 01m Memory: 15.58 GiB used: 2.30 GiB (14.8%) Init: systemd v: 242 Compilers: 
           gcc: 9.2.0 Shell: bash v: 5.0.11 running in: gnome-terminal inxi: 3.0.37 

Try the 4.19 kernel and see if the problem persists.

It appears to be working, but I will need some time to test it out.

Yea, there have been some reports of Ethernet connections not working properly with the 5.4 kernel.
I don't know if this has something to do with power management, or what. However, there have been reports of other issues with the 5.4 kernel as well.

Personally, I had disk I/O issues on one of my systems so bad, that it almost seemed frozen.
That is, if it wasn't for the fact that things would happen 15 to 20 minutes after I did them (aka right click on the desktop, etc.).

Unfortunately, today after a couple of hours suspension this problem appeared again. This time, plugin and unplugging a cable solved it, but issue is still there..

A suspend service should correct this:

I have to agree here, there was once a time when the external r8168 module was the only one available, and for a time after it was a bit better than the internal r8169 kernal module. This is no longer the case, and the r8168 module actually causes more issues than it used to solve. To remove this driver and use the kernels r8169 driver module just go into the Manjaro hardware configuration manager and remove it (right click, remove).

After that reboot your system, that is unless you already know how to use modprobe, then just remove the r8168 from memory, and load up the r8169 kernel module.

I merely posted the R8168/R8169 suspend service as an example. The OP will need to swap in his pertinent network details to customize the service to his application.

The OP's adapter's designation is different than “enp2s0”, so you will need to substitute "eno1" into the service file.

The OP will also need to substitute "e1000e" in place of “r8168” or “r8169” in the service file.

This service I posted (when modified correctly) usually works to fix suspend issues with most Ethernet adapters.

Oops, my bad.
I thought this was that darn Realtek adaptor issue again.
I see now that it is not.
I do apologize for my confusion.

1 Like

You should've said earlier that I had to modify this script, thanks to @AJSlye post I managed to set it correctly I guess. Thank you for help anyway :slight_smile:

Why should I have needed to say that. That information was already included in the Link to the service which I already posted. If you had read the entire post carefully, instead of simply copy and pasting the service you would have known that. The information that the service needed modification if using a different adapter was already included there.

From the link I posted with the service, and I quote:

Please be so kind as to post your working service and I will put a link to it on my systemd service thread. That way users of e1000e based Intel adapters can follow your example.

I'm glad that fixed your issue.

My bad I didn't see it. If it comes to this script, as far as I can see this is not the best solution, as it takes some time to load it up, although it works, so until there is not updated kernel with the fix here's my version.

#/etc/systemd/system/network-restart.service
#sudo systemctl enable network-restart.service
#sudo systemctl start network-restart.service
#sudo systemctl stop network-restart.service
#sudo systemctl disable network-restart.service
#systemctl status network-restart.service

[Unit]
Description=Network Suspend/Resume Service 
Before=sleep.target
StopWhenUnneeded=yes

[Service]
User=root
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking off'
ExecStart=/usr/bin/sleep 1
ExecStart=-/usr/bin/systemctl stop NetworkManager
ExecStart=/usr/bin/sleep 1
ExecStart=-/usr/bin/ip link set eno1 down	
ExecStart=/usr/bin/sleep 1
ExecStart=-/usr/bin/modprobe -r e1000e
ExecStop=-/usr/bin/modprobe e1000e
ExecStop=/usr/bin/sleep 2
ExecStop=-/usr/bin/ip link set eno1 up
ExecStop=/usr/bin/sleep 2
ExecStop=-/usr/bin/systemctl start NetworkManager
ExecStop=/usr/bin/sleep 1
ExecStop=-/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking on'

[Install]
WantedBy=sleep.target

You can often remove the sleep times and the service will still work. Play with the sleep times if if the startup is too laggy for you. The most important sleep time is the one just before the modprobe command. Different systems respond differently. On some systems the service won't work reliably without the sleep units, and others can do OK without them.

Thanks for posting your version.

I certainly will, thanks for the help.

1 Like

No problem, you're welcome.

Forum kindly sponsored by