r8169 ethernet card don't work after returning from suspension

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1752772

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

you might need to install both: r8168-dkms & libelf.dev (a r8168 report already exist on launchpad)

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16-rc4

Using the 4.16-rc4 kernel have not made the network card work after suspension and, when I try to wake up the system it is remounting the file system as read only and I can't open Firefox, so I'm reporting from another computer now.

dino99's solution wouldn't break Secure Boot? Also, it works fine on 16.04, as I could suspend the system and it would wake up with no problems with that version.

Please find the first bad -rc* kernel that has this issue.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/

The last version working properly is 4.15-rc4. 4.15-rc5 don't suspend (it fails to) and, starting from 4.15-rc6, this problem with the Ethernet card appears.

Do you still have this issue on v4.16-rc4?

Yes, with 4.16-rc4 and 4.16-rc5 the problem persists. Every kernel version after 4.15-rc5 is making the computer lose connectivity after returning from suspension.

Status changed to 'Confirmed' because the bug affects multiple users.

Can you do a kernel bisection?

First, find the last good -rc kernel and the first bad -rc kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/

Then,
$ sudo apt build-dep linux
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ git bisect start
$ git bisect good v4.15-rc4
$ git bisect bad v4.15-rc6
$ make localmodconfig
$ make -j`nproc` deb-pkg
Install the newly built kernel.
If the issue still happens,
$ git bisect bad
Otherwise,
$ git bisect good
Repeat to "make -j`nproc` deb-pkg" until you find the commit that causes the regression.

The kernels built using this procedure are not working properly. The screen is limited at 640x480 and, after suspending and trying to restore, the screen never turns on again, even trying to change to a tty don't work, so I can't test because I can't see anything.

Right, I have two desktops that have this card. Let me see if I can reproduce the issue on them.

This is the bad commit:

commit bc976233a872c0f20f018fb1e89264a541584e25
Author: Thomas Gleixner <email address hidden>
Date: Fri Dec 29 10:47:22 2017 +0100

    genirq/msi, x86/vector: Prevent reservation mode for non maskable MSI

I'll report the issue to upstream maintainers.

https://lkml.org/lkml/2018/3/30/508

just testing ubuntu 18.04 beta 2 and have this exact same problem. removing and reloading the r8169 module fixes the problem, but i think it's a serious bug if networking is completely lost on every system suspend...

most users will not troubleshoot enough or be able to unload/reload drivers, having networking completely fail after every suspend is more than medium severity for what is tyo be an lts release.

Can you try latest mainline kernel again? At least the issue is gone for me with latest mainline kernel.

I'll do a reverse bisect to find the commit that fixes the issue, and backport the patch to Bionic's kernel.

i just installed the latest mainline kernel available in the mainline ppa which was 4.16.1-041601-generic_4.16.1-041601.201804081334 and the problem is just the same.

Okay, can you use the patch [1] and attach dmesg after resume?

[1] https://lkml.org/lkml/2018/4/3/136

With a different install of Bionic in my notebook, the problem is happening too. This appears on dmesg:

[ 95.285073] ------------[ cut here ]------------
[ 95.285109] NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out
[ 95.285165] WARNING: CPU: 3 PID: 0 at /build/linux-5s7Xkn/linux-4.15.0/net/sched/sch_generic.c:323 dev_watchdog+0x221/0x230
[ 95.285170] Modules linked in: rfcomm ccm xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 bridge stp llc devlink ebtable_filter ebtables bnep binfmt_misc nls_iso8859_1 arc4 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp snd_soc_sst_ipc snd_soc_acpi snd_soc_core media snd_compress rtsx_usb_ms memstick btusb btrtl btbcm btintel bluetooth ecdh_generic snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_codec_generic ac97_bus snd_pcm_dmaengine snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm ip6t_REJECT snd_seq_midi nf_reject_ipv6 snd_seq_midi_event xt_hl ip6t_rt ath10k_pci ath10k_core ath mac80211 cfg80211 snd_rawmidi snd_seq snd_seq_device snd_timer nf_conntrack_ipv6
[ 95.285324] nf_defrag_ipv6 intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc input_leds aesni_intel aes_x86_64 crypto_simd glue_helper cryptd intel_cstate intel_rapl_perf joydev serio_raw intel_wmi_thunderbolt snd mei_me mei shpchp soundcore intel_pch_thermal ipt_REJECT nf_reject_ipv4 ideapad_laptop sparse_keymap xt_limit tpm_crb mac_hid acpi_pad xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack sch_fq_codel libcrc32c iptable_filter parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid rtsx_usb_sdmmc hid rtsx_usb uas usb_storage i915 i2c_algo_bit drm_kms_helper
[ 95.285473] syscopyarea sysfillrect sysimgblt fb_sys_fops ahci r8169 psmouse drm libahci mii wmi video
[ 95.285511] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.15.0-20-generic #21-Ubuntu
[ 95.285515] Hardware name: LENOVO 80UG/Toronto 4A2, BIOS 0XCN43WW 07/10/2017
[ 95.285531] RIP: 0010:dev_watchdog+0x221/0x230
[ 95.285542] RSP: 0018:ffff9158f3583e58 EFLAGS: 00010286
[ 95.285549] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 95.285554] RDX: 0000000000040400 RSI: 00000000000000f6 RDI: 0000000000000300
[ 95.285558] RBP: ffff9158f3583e88 R08: 0000000000000001 R09: 000000000000042a
[ 95.285562] R10: ffff9158f3583ee0 R11: 0000000000000000 R12: 0000000000000001
[ 95.285567] R13: ffff9158e971e000 R14: ffff9158e971e478 R15: ffff9158de262480
[ 95.285574] FS: 0000000000000000(0000) GS:ffff9158f3580000(0000) knlGS:0000000000000000
[ 95.285579] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 95.285584] CR2: 00007f4ee6b2a000 CR3: 00000001ff80a001 CR4: 00000000003606e0
[ 95.285590] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 95.285594] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 95.28559...

I cloned git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack and checked out tag v4.16.5, applied the 6 patches listed at the top of http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.16.5/ and the one debug patch at https://lkml.org/lkml/2018/4/3/136.

journalctl before/during/after suspend&resume (see below for journalctl after removing and modprobing the r8169 module):

Apr 29 00:17:38 flo-desktop systemd[1]: Reached target Sleep.
Apr 29 00:17:38 flo-desktop systemd[1]: Starting Suspend...
Apr 29 00:17:38 flo-desktop systemd-sleep[1950]: Suspending system...
Apr 29 00:17:38 flo-desktop kernel: PM: suspend entry (deep)
Apr 29 00:17:38 flo-desktop kernel: PM: Syncing filesystems ... done.
Apr 29 00:17:55 flo-desktop kernel: Freezing user space processes ... (elapsed 0.004 seconds) done.
Apr 29 00:17:55 flo-desktop kernel: OOM killer disabled.
Apr 29 00:17:55 flo-desktop kernel: Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
Apr 29 00:17:55 flo-desktop kernel: Suspending console(s) (use no_console_suspend to debug)
Apr 29 00:17:55 flo-desktop kernel: serial 00:04: disabled
Apr 29 00:17:55 flo-desktop kernel: sd 1:0:0:0: [sdb] Synchronizing SCSI cache
Apr 29 00:17:55 flo-desktop kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Apr 29 00:17:55 flo-desktop kernel: sd 0:0:0:0: [sda] Stopping disk
Apr 29 00:17:55 flo-desktop kernel: sd 1:0:0:0: [sdb] Stopping disk
Apr 29 00:17:55 flo-desktop kernel: ACPI: Preparing to enter system sleep state S3
Apr 29 00:17:55 flo-desktop kernel: PM: Saving platform NVS memory
Apr 29 00:17:55 flo-desktop kernel: Disabling non-boot CPUs ...
Apr 29 00:17:55 flo-desktop kernel: IRQ9: New affinity: 0-3 effective: 2
Apr 29 00:17:55 flo-desktop kernel: IRQ25: New affinity: 0,2-3 effective: 0
Apr 29 00:17:55 flo-desktop kernel: IRQ 25: no longer affine to CPU1
Apr 29 00:17:55 flo-desktop kernel: smpboot: CPU 1 is now offline
Apr 29 00:17:55 flo-desktop kernel: IRQ9: New affinity: 0-3 effective: 0
Apr 29 00:17:55 flo-desktop kernel: IRQ12: New affinity: 0-3 effective: 3
Apr 29 00:17:55 flo-desktop kernel: IRQ17: New affinity: 0-3 effective: 0
Apr 29 00:17:55 flo-desktop kernel: IRQ22: New affinity: 0,3 effective: 3
Apr 29 00:17:55 flo-desktop kernel: IRQ 22: no longer affine to CPU2
Apr 29 00:17:55 flo-desktop kernel: smpboot: CPU 2 is now offline
Apr 29 00:17:55 flo-desktop kernel: IRQ1: New affinity: 0-3 effective: 0
Apr 29 00:17:55 flo-desktop kernel: IRQ12: New affinity: 0-3 effective: 0
Apr 29 00:17:55 flo-desktop kernel: IRQ14: New affinity: 0-3 effective: 0
Apr 29 00:17:55 flo-desktop kernel: IRQ16: New affinity: 0 effective: 0
Apr 29 00:17:55 flo-desktop kernel: IRQ 16: no longer affine to CPU3
Apr 29 00:17:55 flo-desktop kernel: IRQ19: New affinity: 0-3 effective: 0
Apr 29 00:17:55 flo-desktop kernel: IRQ22: New affinity: 0,3 effective: 0
Apr 29 00:17:55 flo-desktop kernel: smpboot: CPU 3 is now offline
Apr 29 00:17:55 flo-desktop kernel: ACPI: Low-level resume complete
Apr 29 00:17:55 flo-desktop kernel: PM: Restoring platform NVS memory
Apr 29 00:17:55 flo-desktop kernel: PCI-DMA: Resuming GART IOMMU
Apr 29 00:17:55 flo-desktop kernel: PCI-DMA: Restoring G...

I forgot this yesterday: I accidentally compiled git master HEAD of that repo first. It worked fine, so something fixed this bug between v4.16.5 and 46dc111dfe47. If required I can try to bisect, but it will take a while, my CPU is almost 10 years old (takes 1+ hour to compile the kernel). I guess I could speed this up by using the pre-compiled debs to find a smaller range of commits first.

These are the affinity debug messages for the patched git master, ____i.e. the network worked correctly after suspend&resume___: (log in my previous comment is from v4.16.5, where the network didn't work after resume)
Apr 28 20:24:01 flo-desktop kernel: ACPI: Preparing to enter system sleep state S3
Apr 28 20:24:01 flo-desktop kernel: PM: Saving platform NVS memory
Apr 28 20:24:01 flo-desktop kernel: Disabling non-boot CPUs ...
Apr 28 20:24:01 flo-desktop kernel: IRQ9: New affinity: 0-3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ25: New affinity: 0,2-3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ 25: no longer affine to CPU1
Apr 28 20:24:01 flo-desktop kernel: smpboot: CPU 1 is now offline
Apr 28 20:24:01 flo-desktop kernel: IRQ12: New affinity: 0-3 effective: 3
Apr 28 20:24:01 flo-desktop kernel: IRQ14: New affinity: 0-3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ17: New affinity: 0-3 effective: 3
Apr 28 20:24:01 flo-desktop kernel: IRQ22: New affinity: 0,3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ 22: no longer affine to CPU2
Apr 28 20:24:01 flo-desktop kernel: smpboot: CPU 2 is now offline
Apr 28 20:24:01 flo-desktop kernel: IRQ1: New affinity: 0-3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ12: New affinity: 0-3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ15: New affinity: 0-3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ16: New affinity: 0 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ 16: no longer affine to CPU3
Apr 28 20:24:01 flo-desktop kernel: IRQ17: New affinity: 0-3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: IRQ19: New affinity: 0-3 effective: 0
Apr 28 20:24:01 flo-desktop kernel: smpboot: CPU 3 is now offline
Apr 28 20:24:01 flo-desktop kernel: ACPI: Low-level resume complete

Can you try v4.17-rc4? There are several genirq fixes.

On 11/05/18 04:47, Kai-Heng Feng wrote:
> Can you try v4.17-rc4? There are several genirq fixes.
>
@ kai.heng.feng - that appears to work for me here

Linux wolf-wolf 4.17.0-041700rc4-generic

From http://kernel.ubuntu.com/~kernel-ppa/mainline/:
works: v4.17-rc1, v4.17-rc3, v4.17-rc4 (-rc2 not tested, but I assume it works)
fails: v4.16.7

build for 4.16.8 failed, so I was unable to test that one.

The kernel version 4.17-rc4 is working for me.

Just upgrade from Xubuntu artful to bionic, and just discovered I face the same issue.

Only modprobe -r r8169 + modprobe r8169 restore the network.

For now running default kernek 4.15.0-20-generic.

Please try this kernel, I pulled the genirq fixes.

https://people.canonical.com/~khfeng/lp1752772/

This kernel did not work, when waking from suspension it shows the same dmesg messages and only reloading the r8169 module the Ethernet works again.

The kernel version 4.17-rc5 is also working for me.

So if this is the solution, how long before it gets into the standard update to folks?

Thanks in advance,
Gary

Sorry for the late reply.
I should be able to find some time and cherry-pick necessary commits this week.

rtimai,

r8169 supports more than 50 different variants. The original bug is for 8168[gh], and yours is r8106e. So it would be better to file a new bug.

I have the same problem on my bionic, and now cosmic, laptop.

Suggesting users raise separate reports for every network interface isn't helpful.

My ethernet controller is RTL 8111/8168/8411.

I have solved this for my laptop, in 2 stages.

First I installed r8168-dkms - the correct driver for my laptop. My network now appears to be up on resuming from suspend.

But I then found I could not open any DNS or IP addresses. Restarting system-resolved did not work. Restarting network-manager did not work. My laptop does run dnsmasq.

I found an answer at https://askubuntu.com/questions/1029250/ubuntu-18-04-ethernet-disconnected-after-suspend which was for an r8169.

This is an edited copy of the solution I found there:

"We need to reload the module for the Ethernet interface when resuming from suspend, after suspend. So I created script /lib/systemd/system-sleep/r8168-refresh:

#!/bin/bash

PROGNAME=$(basename "$0")
state=$1
action=$2

function log {
    logger -i -t "$PROGNAME" "$*"
}

log "Running $action $state"

if [[ $state == post ]]; then
    modprobe -r r8168 \
    && log "Removed r8168" \
    && modprobe -i r8168 \
    && log "Inserted r8168"
fi
and made it executable:

chmod +x /lib/systemd/system-sleep/r8168-refresh

The messages logged from the script will go to /var/log/syslog tagged with the name of the script and its PID. This way you can check whether the script reloaded the kernel module"

This fixed my laptop. There are other suggested ways of doing similar things in the link above.

also occurs with sky2 driver

Also happens with driver=r8152 driverversion=v1.09.9. I'm on an Ubuntu dell xps-13 and I'm using a dock station where the ehternet cable is wired.

Olivers, please file a new bug as r8151 is a completely different device.

Regarding my previous comment
"4.15.0-24-generic resolved the problem for me."
That is true for my Asus N53SV laptop.

However I have a desktop motherboard with onboard
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)

Where I have discovered this issue is occurring on Kernel
Linux 4.15.0-43-generic #46-Ubuntu

I have made a temporary workaround for my desktop like so:

#####
#/etc/systemd/system/fix-r8169.service

[Unit]
Description=Fix RTL-8169 Driver on resume from suspend
After=suspend.target

[Service]
User=root
Type=oneshot
ExecStartPre=[[ $(uname --kernel-release) == "4.15.0-43-generic" ]] && /sbin/modprobe -r r8169
ExecStart=[[ $(uname --kernel-release) == "4.15.0-43-generic" ]] && /sbin/modprobe r8169
TimeoutSec=0
StandardOutput=syslog

[Install]
WantedBy=suspend.target

#systemctl enable fix-r8169.service
#####

This script gives new kernels the opportunity to get it right.
If I update and the new kernel is not working, I'll update the kernel version in the systemd service.

I thought my above script was working, but lately it hasn't worked.
So I changed it to this now, disabled then enabled the service and it worked when I tested it now.

Change the 2 lines above to these

ExecStartPre=/bin/bash -c '[[ $(uname --kernel-release) == "4.15.0-43-generic" ]] && /sbin/modprobe -r r8169'
ExecStart=/bin/bash -c '[[ $(uname --kernel-release) == "4.15.0-43-generic" ]] && /sbin/modprobe r8169'

i solved my problem of "ethernet card don't work after returning from suspension" by updating kernel from 4.15 to 4.20 (Ubuntu 18.04 Bionic) using UKUU
to install the latest kernel install Ubuntu Kernel Update Utility
$ sudo add-apt-repository ppa:teejee2008/ppa
$ sudo apt-get install ukuu
disable access control with the following command:
$ sudo xhost +
then install with ukuu
$ sudo ukuu
$ sudo ukuu --install-latest
and reboot
$ sudo reboot

I am also affected by this bug.
uname -a
Linux platinum-ubuntu 4.15.0-29-generic #31-Ubuntu SMP Tue Jul 17 15:39:52 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

sudo lshw -C network
  *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
capabilities: pm vpd msi pciexpress bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full ip=192.168.1.1 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s

And, after running the Ubuntu software update, the problem still exists with 4.15.0-43
uname -a
Linux platinum-ubuntu 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Doing the following workaround will 'fix' the bring the ethernet back up for me also.
  sudo modprobe -r r8169
  sudo modprobe -i r8169

Maybe a 'fix' will be released which will work through the normal system update.

Please test the kernel in -proposed, thanks!

Is this issue fixed in 4.18.0-17-generic #18~18.04.1-Ubuntu SMP Fri Mar 15 15:27:12 UTC 2019?

I have just done a fresh install. Modprobe workaround doesn't seem to work. Happy to provide any information required.

gordon:~$ sudo lshw -C network

  *-network
       description: Wireless interface
       product: Wireless 7260
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: wlp2s0
       version: 73
       serial: 0c:8b:fd:48:fe:40
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=4.18.0-17-generic firmware=17.948900127.0 ip=192.168.69.113 latency=0 link=yes multicast=yes wireless=IEEE 802.11
       resources: irq:46 memory:e3500000-e3501fff
  *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0.1
       bus info: pci@0000:03:00.1
       logical name: enp3s0f1
       version: 12
       serial: 78:45:c4:c9:4e:61
       size: 10Mbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=half firmware=rtl8411-2_0.0.1 07/08/13 latency=0 link=no multicast=yes port=MII speed=10Mbit/s
       resources: irq:19 ioport:4000(size=256) memory:e3404000-e3404fff memory:e3400000-e3403fff

Gordon,
Please file a separate bug report, thanks.

My HP ProBook 6540b has the following hardware:
  *-network
       description: Ethernet interface
       product: 88E8072 PCI-E Gigabit Ethernet Controller
       vendor: Marvell Technology Group Ltd.
       physical id: 0
       bus info: pci@0000:45:00.0
       logical name: ens1
       version: 10
       serial: 70:5a:b6:b2:9f:50
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm vpd msi pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=sky2 driverversion=1.30 duplex=full ip=192.168.1.23 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:29 memory:d0500000-d0503fff ioport:2000(size=256) memory:d0520000-d053ffff

This problem exist after fresh install and after upgrade from ubuntu 16.04.

Im having the same bug in Kubuntu 19.04 Kernel 5.0.0-15-generic
Using the following commands fixes the problem till next suspend

sudo modprobe -r r8169
sudo modprobe -i r8169

The same problem in Xubuntu 18.04.2 with kernel 4.15.0-54. The fix is:

sudo modprobe -r r8169
sudo modprobe -i r8169

Please reopen the issue.

Since changes were introduced with 4.15.0-24, the r8169 driver becomes unusable on x86 machines (16.04 and 18.04 distributions). The device is always in link down state.

I'm having the same bug in Kubuntu 19.04.03 Kernel 5.0.0-25-generic

This bug must be opened again

Ricci,

I guess yours is LP: #1841040? Let's discuss the issue on LP: #1841040 instead.

I can confirm the bug affects kernel version 5.0.0-25-generic (at least, on my machine).
The issue started happening after update to this version.
It didn't exist on any 4.18.0 version that I previously had.

Same here with kernel 5.0.0-25-generic, however the script from post #120 seems to work around this.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772/comments/120

After update to kernel 5.0.0-27-generic, it became even worse.
Now Ethernet doesn't work right from the boot, and "modprobe" solution has no effect.

What's interesting, Ethernet interface seems up (and visible to NewtworkManager), but doesn't appear to serve packets at all. As far as packet statistics go, packets are transmitted, but never received.

UPD: The same issue, as described in previous post, reappeared when booting the older 5.0.0-25-generic kernel.
It seems like data race that can be triggered randomly on certain boots.

Again, removing "r8169" didn't help either, but suddenly, putting my laptop to suspension, then repeating the module removal process resolved it.

Can you please test versions >= 5.0.0-30.32? Particularly,
commit 67d0bc70365cc6936255914e900a1362c608a381
Author: Heiner Kallweit <email address hidden>
Date: Sat Jul 27 12:45:10 2019 +0200

    r8169: don't use MSI before RTL8168d

    BugLink: https://bugs.launchpad.net/bugs/1841994

    [ Upstream commit 003bd5b4a7b4a94b501e3a1e2e7c9df6b2a94ed4 ]

    It was reported that after resuming from suspend network fails with
    error "do_IRQ: 3.38 No irq handler for vector", see [0]. Enabling WoL
    can work around the issue, but the only actual fix is to disable MSI.
    So let's mimic the behavior of the vendor driver and disable MSI on
    all chip versions before RTL8168d.

    [0] https://bugzilla.kernel.org/show_bug.cgi?id=204079

    Fixes: 6c6aa15fdea5 ("r8169: improve interrupt handling")
    Reported-by: Dušan Dragić <email address hidden>
    Tested-by: Dušan Dragić <email address hidden>
    Signed-off-by: Heiner Kallweit <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>
    Signed-off-by: Kamal Mostafa <email address hidden>
    Signed-off-by: Kleber Sacilotto de Souza <email address hidden>

I am also affected by this bug.

WLAN device wlp2s0 under Live Kubuntu 19.10.

Network Manager did not show anything after Laptop lid closed (-> suspended)

solution was:

 sudo modprobe -r DRIVER
 sudo modprobe -i DRIVER

Replace DRIVER from
 sudo lshw -C network
under configuration: ...driver=DRIVER

Simply run: sudo /etc/init.d/network-manager restart. Then the network comes back.

@edwin, this takes one full minute to complete, which kind of defeats the purpose of suspending. I could almost do a full cold boot in that time.

Before, the network would be up within seconds.

Seeing this with r8152 on 20.04 (Regolith 1.4) with kernel 5.4.0-29
Will try reloading the driver after my next resume.

same problem here with r8152 on 19.10 (Eoan Ermine) kernel 5.0.0-1030-oem-osp1
the modprobe -r / -i trick fixes it when resuming from suspended state.
laptop is a Dell XPS 13 7390 but the wired ethernet device is on a TB16 dock so lshw shows its on a usb bus rather than pci -
  *-network:2
       description: Ethernet interface
       physical id: 3
       bus info: usb@6:1.2
       logical name: enx98e743d454f3
       serial: 98:e7:43:d4:54:f3
       size: 1Gbit/s
       capacity: 1Gbit/s
       capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8152 driverversion=v1.09.9 duplex=full ip=192.168.10.90 link=no multicast=yes port=MII speed=1Gbit/s

Mark,

Please file a separate bug for r8152.

I'm affected too. Noticed a few months back after updates resuming from suspend became obnoxiously slow, almost 2 minutes to resume the network interface. Meanwhile the system is trying to remount network drives and failing because there is no network so clearly the system isn't in sync with itself. Super obnoxious!

Perhaps should have added more info as I didn't notice someone with a different adapter posting before me which may lead people to think I am chiming in about the r8152 rather than the r8169.

Ubuntu 18.04.4 LTS

Linux $HOST 5.4.0-42-lowlatency #46~18.04.1-Ubuntu SMP PREEMPT Fri Jul 10 08:10:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

lsmod shows r8169 is loaded

dmesg (around 90-100 seconds from wake to get this message)
[ +0.055012] Generic FE-GE Realtek PHY r8169-2200:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-2200:00, irq=IGNORE)
[ +0.082018] r8169 0000:22:00.0 enp34s0: Link is Down
[ +3.341998] r8169 0000:22:00.0 enp34s0: Link is Up - 1Gbps/Full - flow control off
[ +0.000009] IPv6: ADDRCONF(NETDEV_CHANGE): enp34s0: link becomes ready

Am using a Lenovo T440s with 19.10 a docking station and an e1000e driver.

lspci -k | grep Ethernet -A2
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04)
 Subsystem: Lenovo ThinkPad X240
 Kernel driver in use: e1000e

I can fix with

sudo rmmod e1000e && sudo modprobe e1000e && sudo systemctl restart network-manager.service

Appears to be similar to #148, so I wonder if this is not ethernet driver related but USB/PCI related?

I tried adding the module to MODULES_WHITELIST and the prefix to SKIP_INTERFACES to my acpi-support...no dice, still takes approx 80 seconds before the interface is brought back up.

[ +0.003247] PM: suspend exit
[ +0.084034] libphy: r8169: probed
[ +0.000214] r8169 0000:22:00.0 eth0: RTL8168h/8111h, XX:XX:XX:XX:XX:XX, XID 541, IRQ 60
[ +0.000002] r8169 0000:22:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ +0.001206] r8169 0000:22:00.0 enp34s0: renamed from eth0
[Aug22 23:34] Generic FE-GE Realtek PHY r8169-2200:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-2200:00, irq=IGNORE)
[ +0.089857] r8169 0000:22:00.0 enp34s0: Link is Down
[ +3.418667] r8169 0000:22:00.0 enp34s0: Link is Up - 1Gbps/Full - flow control rx/tx
[ +0.000011] IPv6: ADDRCONF(NETDEV_CHANGE): enp34s0: link becomes ready
[ +0.002452] r8169 0000:22:00.0 enp34s0: Link is Down
[ +3.483014] r8169 0000:22:00.0 enp34s0: Link is Up - 1Gbps/Full - flow control off

Is anything going on with this? It's been quite a while. I recently retested and the r8169 still will not wake for 80+ seconds upon wake.

This issue affect me.
The problem occurs after a resume from suspend, BUT, restart DON'T SOLVE, I need to choose POWER OFF.
IMPORTANT (I believe): I'm running in dual boot Ubuntu/Windows 10. If I RESTART on WINDOWS 10, without POWER OFF, network does not work, also. I need to RESTART. I believe that something is setted on HDW LEVEL.
Hdw: ASUS=TP500l
Linux version 5.13.0-39-generic (buildd@lcy02-amd64-080) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #44~20.04.1-Ubuntu SMP Thu Mar 24 16:43:35 UTC 2022
Journalctl from suspend start to error and some TURN OFF/ON on devic, attached.

this is still an issue in 2023

Bump. Still an issue. I am running on a ASUS ROG G751J. For me it has some weird behaviour depending on if I open the lid after suspend, or if I just wake it using keyboard and mouse and leave the lid closed (using a external monitor).