Intel I218-V 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.

Okay, never mind it didn't help me.. Rebooting, restarting manually the service doesn't work. Any other ideas?

Try masking tlp as a test.

Test to see if tlp is causing this by disabling tlp temporarily.

To prevent tlp from starting it can be masked:

sudo systemctl mask tlp && sudo systemctl mask tlp-sleep.service

Reboot, then test if the problem persists.

If there is no improvement by disabling tlp, then simply unmask tlp.

To re-enable tlp:

sudo systemctl unmask tlp && sudo systemctl unmask tlp-sleep.service

Then restart.

Have you tested kernel 5.5?

Alright, I set it up. I let you know if problem persists. According to the kernel, I would rather stay on stable release, but I may try it.

It didn't help at all, I've tried to plug and unplug cable to 3 different sockets in my router, also rechecked if cable might've been an issue. I have no idea, how does it work, because this problem persists even if I turn off my computer and disconnect it from socket.

I have responded to more posts than I could possibly recall with respect to the Intel 200 series of adapters and the e1000e driver. If you search the forum you will find many posts with other fixes you could test for your hardware.

Some of the other fixes you could test off the top of my head:

Install the kernel headers and the e1000e driver from the AUR.

Install and test different versions of the linux-firmware.

Test all kernels from 4.4 to 5.5.

Disable IPv6.

Ensure your BIOS is up to date.

Ensure your router firmware is up to date.

Reset your router back to the factory default settings.

Be sure your speed is set to "auto-negotiation".

Be sure your MTU is set to 1500.

Turn on "enable Wake-on-LAN" in the BIOS. If it is already on, test with it off.

Try removing and re-seating your LAN card (if not onboard) and swap it to another slot (if available).

Try a hard power down reset. Power off the computer, unplug all the power sources from the unit (remove battery if present). Press the power button for 20 secs without any power. Plug the power back in, and power the system back up. Enter the bios and reset the bios to the factory default, save the settings then boot into Manjaro.

I'm sure you can find other fixes to test if you look further into these issues. Please avail yourself of the forums search feature if you need clarification of any steps you need to perform.

Good luck.

Forum kindly sponsored by