Connectivity issues after waking up

[ratijas]

Using built-in into kernel r8169 module, I had issues with interface literally being unreachable / missing / semi-non-visible to the system iff laptop is working on batteries and Ethernet twisted pair was unplugged and plugged back in.

Module r8168 solves the "battery curse" it seems. But now I have another problem.

After waking up from sleeping state (definitely not hibernate — never tried that one), I'm loosing connectivity on the port. Symptoms are similar. While NetworkManager attempts to establish a connection, dmesg -w shows this line after a certain timeout:

[44819.574442] r8168: enp3s0: link up
[44819.606748] __common_interrupt: 2.36 No irq handler for vector
[44820.597876] r8168: enp3s0: link down
[44822.667766] r8168: enp3s0: link up
[44822.681759] __common_interrupt: 2.36 No irq handler for vector

Demonstration on a video:

Forgot to show that on a video, but here's an output of ethtool as well:

❯ # woke up after sleep
❯ sudo ethtool enp3s0
Settings for enp3s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: Unknown
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: no

❯ # Connecting cable...
❯ sudo ethtool enp3s0
Settings for enp3s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 100Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: Unknown
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

---

Realtek, pls fix

[ratijas]

As a workaround, I wrote a little script to reload r8168 kernel module and put it in $PATH. Then I added a systemd hook in /usr/lib/systemd/system-sleep/ to trigger it on waking up.

$ ls /usr/bin/r8168-reload.sh
-rwxr-xr-x root root /usr/bin/r8168-reload.sh

$ cat /usr/bin/r8168-reload.sh
#!/bin/sh

# Fix ethernet port voiding out after sleep

rmmod    r8168
modprobe r8168

$ ls /usr/lib/systemd/system-sleep/r8168
-rwxr-xr-x root root /usr/lib/systemd/system-sleep/r8168

$ cat /usr/lib/systemd/system-sleep/r8168
#!/bin/sh

case "$1" in
    pre) ;;
    post) /usr/bin/r8168-reload.sh ;;
esac

/* I wonder, would it make sense to send a pull request to Arch Linux package adding these scripts? Probably, not. */

[mtorromeo]

You found a good solution. I would suggest removing the module in pre and loading it in post:

#!/bin/bash

case $1 in
  pre) /usr/bin/rmmod r8168 ;;
  post) /usr/bin/modprobe r8168 ;;
esac

Adding the script to Arch would complicate packaging a bit since the script would be needed by both r8168 and r8168-lts, nothing that cannot be solved.

The other concern would be that I don't know if this is needed with every card supported by this driver and I don't even have a pc with a card to test it with.

[ratijas]

I thought about that, but then I realized something.

1. What if module doesn't actually die on suspend -- but rather only screws up on resume? If we remove it too early, we'd lose an ability to Wake-on-LAN, for example.
2. Also, there's a second argument to systemd sleep scripts: suspend, hibernate or hybrid-sleep. I haven't tested them all, which is to say, reloading might not be needed in all those cases.

[Earthling-Z3R0]

I am having the same issue as of this day even though my Arch system just got an r8168 update. The script is working just fine for me as a workaround so thanks for that! Just wondering if there could be a fix implemented that wouldn't require people to set up a workaround.

[mtorromeo]

@Earthling-Z3R0 the best you can hope is for workarounds here, as this repo only hosts a mirror. You should contact Realtek for a real fix (good luck with that).

[runderwo]

Maybe it's related to this MSI bug with early r8168 versions that was fixed in the mainline r8169 driver? https://bugzilla.kernel.org/show_bug.cgi?id=204079