r8169 ethernet card don't work after returning from suspension

Bug #1752772 reported by Leonardo Müller
878
This bug affects 199 people
Affects Status Importance Assigned to Milestone
Linux
New
Undecided
Unassigned
linux (Ubuntu)
Fix Released
Medium
Unassigned
Bionic
Fix Released
Undecided
Unassigned
linux-kernel-headers (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

===SRU Justification===
[Impact]
Ethernet r8169 stops working after system resumed from suspend.

[Test]
User confirmed these patches fix the issue. r8169 continues to work
after resume from suspend.

[Regression Potential]
Medium. The fix is limited to one device, all patches are in mainline.
The WOL default change might cause regression for users that depend on
BIOS settings. We can advice them to use userspace tool (systemd,
ethtool, etc.) instead.

===Original Bug Report===
I have noticed that the network stopped working on my desktop after I've suspended the system and woke it up. On dmesg there are messages like:

[ 150.877998] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready
[ 150.944101] do_IRQ: 3.37 No irq handler for vector
[ 150.944105] r8169 0000:01:00.0 enp1s0: link down
[ 150.944180] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready

When using Xenial (from a different install), this problem is not happening. This is happening on Bionic.

There are only two ways to restore connectivity:
1) Reboot the system;
2) Remove the r8169 module and reinsert it with modprobe.

The motherboard is a AsRock H55M-LE and the Ethernet controller is:

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-firmware 1.172
ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
Uname: Linux 4.15.0-10-generic x86_64
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
CurrentDesktop: LXDE
Date: Fri Mar 2 00:21:57 2018
Dependencies:

InstallationDate: Installed on 2018-02-26 (3 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180226)
PackageArchitecture: all
SourcePackage: linux-firmware
UpgradeStatus: No upgrade log present (probably fresh install)
---
AlsaVersion: Advanced Linux Sound Architecture Driver Version k4.15.0-10-generic.
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: MID [HDA Intel MID], device 0: VT1818S Analog [VT1818S Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: usuario 1153 F.... pulseaudio
 /dev/snd/controlC1: usuario 1153 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'MID'/'HDA Intel MID at 0xfbdf8000 irq 26'
   Mixer name : 'VIA VT1818S'
   Components : 'HDA:11060440,18492818,00100000'
   Controls : 40
   Simple ctrls : 17
Card1.Amixer.info:
 Card hw:1 'HDMI'/'HDA ATI HDMI at 0xfbffc000 irq 27'
   Mixer name : 'ATI R6xx HDMI'
   Components : 'HDA:1002aa01,00aa0100,00100200'
   Controls : 7
   Simple ctrls : 1
Card1.Amixer.values:
 Simple mixer control 'IEC958',0
   Capabilities: pswitch pswitch-joined
   Playback channels: Mono
   Mono: Playback [on]
CurrentDesktop: LXDE
Dependencies:

DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=UUID=edd83175-c707-4b31-90d2-ce2f5cebc73f
InstallationDate: Installed on 2018-02-26 (3 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180226)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
Package: linux-firmware 1.172
PackageArchitecture: all
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz root=UUID=0c4fc517-b7a0-49b0-bfcb-0485dfe6413b ro quiet
ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-10-generic N/A
 linux-backports-modules-4.15.0-10-generic N/A
 linux-firmware 1.172
RfKill:

Tags: bionic
Uname: Linux 4.15.0-10-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirt lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 10/20/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.80
dmi.board.name: H55M-LE
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.80:bd10/20/2010:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnH55M-LE:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

CVE References

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

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.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Leonardo Müller (leozinho29-eu) wrote : AlsaDevices.txt

apport information

tags: added: apport-collected
description: updated
Revision history for this message
Leonardo Müller (leozinho29-eu) wrote : AplayDevices.txt

apport information

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote : CRDA.txt

apport information

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote : Card0.Amixer.values.txt

apport information

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote : Card0.Codecs.codec.0.txt

apport information

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote : Card1.Codecs.codec.0.txt

apport information

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote : IwConfig.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
dino99 (9d9) wrote :

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

Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

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

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

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.

tags: added: kernel-bug-exists-upstream
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

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

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux-firmware (Ubuntu):
status: New → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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.

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

no longer affects: linux-firmware (Ubuntu)
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Changed in linux (Ubuntu):
assignee: nobody → Kai-Heng Feng (kaihengfeng)
Revision history for this message
elguavas (elguavas.) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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.

Revision history for this message
elguavas (elguavas.) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

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

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :
Download full text (4.7 KiB)

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...

Read more...

Revision history for this message
Florian W. (florian-will) wrote :
Download full text (11.6 KiB)

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...

Revision history for this message
Florian W. (florian-will) wrote :

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

no longer affects: linux
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

Revision history for this message
Kev Bowring (flocculant) wrote : Re: [Bug 1752772] Re: r8169 ethernet card don't work after returning from suspension

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

Revision history for this message
Florian W. (florian-will) wrote :

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.

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

The kernel version 4.17-rc4 is working for me.

Revision history for this message
Guillaume LAURENT (laurent-guillaume) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please try this kernel, I pulled the genirq fixes.

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

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

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.

Revision history for this message
Dark Dragon (darkdragon-001) wrote :

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

Revision history for this message
Gary Liberson (libergm) wrote :

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

Thanks in advance,
Gary

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

Revision history for this message
Anibal Sanchez (anibal-sanchez) wrote :

Same issue here. It was working fine on v16.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please test the kernel here, it fixes the issue for me:
https://people.canonical.com/~khfeng/lp1752772-r8169-intx/

Revision history for this message
eric-1111 (eric-1111) wrote :
description: updated
Revision history for this message
Kev Bowring (flocculant) wrote :

Works fine for me too.

Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

It is working for me too.

Revision history for this message
Kleber Sacilotto de Souza (kleber-souza) wrote :

Nominating for Bionic.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu Bionic):
status: New → Confirmed
Changed in linux (Ubuntu Bionic):
status: Confirmed → Invalid
status: Invalid → Confirmed
Changed in linux (Ubuntu Bionic):
status: Confirmed → Fix Committed
Sergey (gesent)
Changed in linux (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Leonardo Müller (leozinho29-eu) wrote :

This kernel update released today have not corrected the problem, but the kernel from https://people.canonical.com/~khfeng/lp1752772-r8169-intx/ works.

Revision history for this message
Florian W. (florian-will) wrote :

Confirming this is still an issue for me after updating my bionic installation to linux-image-4.15.0-23-generic 4.15.0-23.25, while https://people.canonical.com/~khfeng/lp1752772-r8169-intx/ worked fine in recent weeks.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

The commits wasn't in kernel -23. Let me check with the kernel team.

Changed in linux (Ubuntu Bionic):
status: Fix Released → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Ok it will be in the next kernel release.

Changed in linux (Ubuntu Bionic):
status: Confirmed → Fix Committed
Revision history for this message
Brad Figg (brad-figg) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-bionic
Revision history for this message
Eric Carvalho (eric-carvalho) wrote :

The kernel in -proposed (4.15.0-23-generic) doesn't solve the problem.

tags: added: verification-failed-bionic
removed: verification-needed-bionic
Revision history for this message
Florian W. (florian-will) wrote :

Eric, I believe your mirror is lagging behind ab it?
I just installed 4.15.0-24-generic from -proposed and it fixes the issue for me (tested 2 suspend cycles – previously it would fail 100% of the time).

tags: added: verification-done-bionic
removed: verification-failed-bionic
Revision history for this message
Eric Carvalho (eric-carvalho) wrote :

Shame on me! I think I've missed an `apt update`. Indeed kernel 4.15.0-24-generic is there an DOES solve the problem. Sorry.

Revision history for this message
Gaël Roualland (gael-roualland-) wrote :

Works perfectly for me too. Thanks!

Revision history for this message
Kev Bowring (flocculant) wrote :

Running cosmic now - was on bionic, this version works fine for me on Cosmic.

Added the verification-done-cosmic tag for better or worse ...

tags: added: verification-done-cosmic
Revision history for this message
Soltész András (soltesz-andras) wrote :

4.15.0-24-generic from bionic-proposed has solved the issue on my Asus N550JK (Kubuntu 18.04)

Revision history for this message
Richard Wall (brickatius) wrote :

4.15.0-24-generic from bionic-proposed has not solved the issue. 2 network cards - one Intel and the other Realtek (r8169). Realtek not found after suspend on previous kernel, now not found on boot either.

Revision history for this message
Richard Wall (brickatius) wrote :

Correction! Realtek network card driver not loaded on boot but after loading with sudo modprobe -r r8169 and sudo modprobe r8169 is still present after suspend so solved one problem and created another.

Revision history for this message
Luke Arms (lkrms) wrote :

Not sure how to tag, but 4.15.0-24-generic has resolved this on my Lenovo ThinkPad E470 -- several suspend and reboot cycles without issue now.

Revision history for this message
Richard Wall (brickatius) wrote :

Network status on boot.
  *-network UNCLAIMED
       description: Ethernet controller
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:05:00.0
       version: 06
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd cap_list
       configuration: latency=0
       resources: ioport:d000(size=256) memory:f7c00000-f7c00fff memory:f0000000-f0003fff

And after modprobe and after suspend.
 *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:05:00.0
       logical name: enp5s0
       version: 06
       serial: 98:de:d0:06:2e:68
       size: 1Gbit/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=full firmware=rtl_nic/rtl8168e-2.fw ip=192.168.2.6 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       resources: irq:18 ioport:d000(size=256) memory:f7c00000-f7c00fff memory:f0000000-f0003fff

Revision history for this message
Luke Arms (lkrms) wrote :

Update: although the Ethernet issue is resolved on my hardware, the Wi-Fi interface ("Intel Corporation Wireless 8265 / 8275 (rev 78)" using iwlwifi according to lspci -v) now seems to be unstable after suspend (reboot required to bring interface up). It's unclear if this is directly related to the patch that's been applied, but seems worth of mention given the stable kernel was the opposite (stable Wi-Fi interface, unstable Ethernet).

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Richard, Luke,

Please file a new bug report for your issues, seems like it's not related to the original bug.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (49.5 KiB)

This bug was fixed in the package linux - 4.15.0-24.26

---------------
linux (4.15.0-24.26) bionic; urgency=medium

  * linux: 4.15.0-24.26 -proposed tracker (LP: #1776338)

  * Bionic update: upstream stable patchset 2018-06-06 (LP: #1775483)
    - drm: bridge: dw-hdmi: Fix overflow workaround for Amlogic Meson GX SoCs
    - i40e: Fix attach VF to VM issue
    - tpm: cmd_ready command can be issued only after granting locality
    - tpm: tpm-interface: fix tpm_transmit/_cmd kdoc
    - tpm: add retry logic
    - Revert "ath10k: send (re)assoc peer command when NSS changed"
    - bonding: do not set slave_dev npinfo before slave_enable_netpoll in
      bond_enslave
    - ipv6: add RTA_TABLE and RTA_PREFSRC to rtm_ipv6_policy
    - ipv6: sr: fix NULL pointer dereference in seg6_do_srh_encap()- v4 pkts
    - KEYS: DNS: limit the length of option strings
    - l2tp: check sockaddr length in pppol2tp_connect()
    - net: validate attribute sizes in neigh_dump_table()
    - llc: delete timers synchronously in llc_sk_free()
    - tcp: don't read out-of-bounds opsize
    - net: af_packet: fix race in PACKET_{R|T}X_RING
    - tcp: md5: reject TCP_MD5SIG or TCP_MD5SIG_EXT on established sockets
    - net: fix deadlock while clearing neighbor proxy table
    - team: avoid adding twice the same option to the event list
    - net/smc: fix shutdown in state SMC_LISTEN
    - team: fix netconsole setup over team
    - packet: fix bitfield update race
    - tipc: add policy for TIPC_NLA_NET_ADDR
    - pppoe: check sockaddr length in pppoe_connect()
    - vlan: Fix reading memory beyond skb->tail in skb_vlan_tagged_multi
    - amd-xgbe: Add pre/post auto-negotiation phy hooks
    - sctp: do not check port in sctp_inet6_cmp_addr
    - amd-xgbe: Improve KR auto-negotiation and training
    - strparser: Do not call mod_delayed_work with a timeout of LONG_MAX
    - amd-xgbe: Only use the SFP supported transceiver signals
    - strparser: Fix incorrect strp->need_bytes value.
    - net: sched: ife: signal not finding metaid
    - tcp: clear tp->packets_out when purging write queue
    - net: sched: ife: handle malformed tlv length
    - net: sched: ife: check on metadata length
    - llc: hold llc_sap before release_sock()
    - llc: fix NULL pointer deref for SOCK_ZAPPED
    - net: ethernet: ti: cpsw: fix tx vlan priority mapping
    - virtio_net: split out ctrl buffer
    - virtio_net: fix adding vids on big-endian
    - KVM: s390: force bp isolation for VSIE
    - s390: correct module section names for expoline code revert
    - microblaze: Setup dependencies for ASM optimized lib functions
    - commoncap: Handle memory allocation failure.
    - scsi: mptsas: Disable WRITE SAME
    - cdrom: information leak in cdrom_ioctl_media_changed()
    - m68k/mac: Don't remap SWIM MMIO region
    - block/swim: Check drive type
    - block/swim: Don't log an error message for an invalid ioctl
    - block/swim: Remove extra put_disk() call from error path
    - block/swim: Rename macros to avoid inconsistent inverted logic
    - block/swim: Select appropriate drive on device open
    - block/swim: Fix array bounds check
    - block/swim: Fix IO error at end of medium
    -...

Changed in linux (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
Lope (lopeonline) wrote :

4.15.0-24-generic resolved the problem for me.

This issue was affecting my Asus N53SV Laptop with "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
It seemed to be more likely to happen after suspend if I had put everything into low power mode with powertop, but I'm not certain about powertop's influence.

I've just dist-upgraded to the new kernel 4.15.0-24-generic and I've tested putting everything into low power mode with powertop, suspending and resuming, and the network adapter is working now.

Revision history for this message
Lope (lopeonline) wrote :

Regarding my previous comment, even though my lspci says I have "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller", the r8169 kernel module is loaded.

Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

For me the update makes things worse instead of better.

Before installing the updated kernel, it only happened from time to time that the ethernet driver had locked up after suspend (and thus needed to be reseted by removing and reloading the module via modprobe).

With the updated linux-image-4.15.0-24-generic installed, it seems to happen _every_ time when I susped that the driver locks up (and needs to be manually reseted). That's quite uncomfortably when the PC is suspended a few times a day and has to be manually fixed by modprobe every time.

Kind regards,
Jan

Revision history for this message
Jan Rathmann (kaiserclaudius) wrote :

Btw. I have tested this with two separate 18.04 installations on different partitions of my PC.

Revision history for this message
MV (mvidal) wrote :

Is it possible this fix is why I have the problem now ?

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

I have this problem since new kernel 4.15.0-24-generic

Revision history for this message
Lope (lopeonline) wrote :

Jan: In the interim you could try other kernels, and you can also make a shell script and add it to your aliases.
If you want it to happen automagically check out the solutions here
https://askubuntu.com/questions/1029250/ubuntu-18-04-ethernet-disconnected-after-suspend/1051852#1051852

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please refer to LP: #1779817 for this new issue.

Revision history for this message
Martin Johnson (martin.d.johnson) wrote :

Not 100% sure if this is exactly related to the RTL issue although it does seem from the posts that other drivers are affected.

I am on an iMac late 2006 with sky2 module and I have also noticed similar issue appear since 4.15.0-24-generic whereas before ethernet worked rock solid on resume from suspend.

[ 1.886780] sky2: driver version 1.30
[ 1.886993] sky2 0000:02:00.0: Yukon-2 EC chip revision 2

uninstalling the sky2 module and reloading it brings it back into a working state.

70% of the time it will fail on suspend / resume, dmesg also shows an IRQ problem when the issue appears:

[ 7008.495941] do_IRQ: 1.35 No irq handler for vector

Previous kernels appear to work fine, so this is clearly something very recently introduced.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Martin,
Please file an new bug, since it's a different ethernet chip.

Revision history for this message
craig p hicks (craigphicks) wrote :

I've been having the same problem after resume. However, although de-modprobe-ing and re-modprobe-ing enables the 'eth0' to be renamed as 'enp2s0', finally it fizzles out with

Jul 06 02:13:24 craig-desktop NetworkManager[5649]: <debug> [1530868404.9510] device[0x2840aa0] (enp2s0): emit RECHECK_ASSUME signal
Jul 06 02:13:24 craig-desktop NetworkManager[5649]: <debug> [1530868404.9510] device[0x2840aa0] (enp2s0): ip4-config: update (commit=0, routes-full-sync=0, new-config=0x285f8f0)
Jul 06 02:13:24 craig-desktop NetworkManager[5649]: <debug> [1530868404.9511] device[0x2840aa0] (enp2s0): ip6-config: update (commit=0, routes-full-sync=0, new-config=0x282a440)
Jul 06 02:13:24 craig-desktop NetworkManager[5649]: <debug> [1530868404.9511] device[0x2840aa0] (enp2s0): device has no existing configuration
Jul 06 02:13:24 craig-desktop NetworkManager[5649]: <debug> [1530868404.9511] manager: (enp2s0): can't assume; no connection

and connectivity fails. Only a reboot fixes it.

Version:
Linux craig-desktop 4.15.0-24-generic #26~16.04.1-Ubuntu SMP Fri Jun 15 14:35:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Past similar reports related to r8169 over the years:

2017 - https://askubuntu.com/a/893823/723997

2011 - https://ubuntuforums.org/showthread.php?t=1661489
 - This 2011 one is interesting because the author points out that ::

   # lspci | grep Realtek
   02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411
    PCI Express Gigabit Ethernet Controller (rev 0c)

   so he replaced r8169 with r8168 and succeeded.

On the other hand, the following set of reports seems to indicate that it is independent of the driver, because of multiple cases where unloading and loading the driver solved the problem although the drivers are different:

2016 - https://forum.ubuntuusers.de/topic/nach-16-10-installation-kein-internet-mehr-nac/2/#post-8652643
     - https://ubuntuforums.org/showthread.php?t=2355314

In conclusion, there might be a deeper bug which is appearing and disappearing with different versions depending upon the random module layout in the compile.

Revision history for this message
Anibal Sanchez (anibal-sanchez) wrote :

Confirmed.

The issue has been solved by 4.15.0-24.26.

Thanks! +1000

Revision history for this message
Wui Chia (wuichia) wrote :

This issue didn't go away even I'm on 4.15.0-24.26

Revision history for this message
RubbelDieCatc (rubbel) wrote :

Had the same problem with debian and kernel 4.16.0-2-amd64

Seems to be a irq problem
Jul 10 08:47:34 xxx kernel: do_IRQ: 13.36 No irq handler for vector
Jul 10 08:47:34 xxx kernel: r8169 0000:18:00.0 enp24s0: link down

Solution is to create a file as root the unloads and reloads the module
vi /lib/systemd/system-sleep/reset-network

#!/bin/sh
if [ "${1}" == "pre" ]; then
  # Do the thing you want before suspend here, e.g.:
  rmmod r8169
elif [ "${1}" == "post" ]; then
  # Do the thing you want after resume here, e.g.:
  modprobe r8169
fi

Don't forget to chmod 755 your script

Revision history for this message
Steve Dodd (anarchetic) wrote :

I'm a bit lost in this bug thread already, but the fix here seems to have caused a regression for me.

I had no problems up until -24, with -24 I can't get the network up after resume, even with module reload.

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

Same as MV above. LMK if more info required or if a new bug is created for this ..

Revision history for this message
David McWilliams (davemcw) wrote :

I have the same problem as Steve Dodd and MV, it worked fine until 4.15.0-24-generic #26-Ubuntu, now my network will not resume after suspend.

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 11)

modprobe -r r8169
modprobe -i r8169
... does not help.

Revision history for this message
Steve Dodd (anarchetic) wrote :

Also affects linux-image-generic-hwe-16.04-edge in xenial.

no longer affects: linux-signed-hwe (Ubuntu)
no longer affects: linux-signed-hwe (Ubuntu Bionic)
Revision history for this message
Steve Dodd (anarchetic) wrote :

Actually, I take that back - my testing (on a different machine) with image-generic-hwe-16.04-edge in xenial is giving inconsistent results.

Revision history for this message
Erik Kallen (erikkallen) wrote :

I have the same problem as Steve Dodd, MV and David McWilliams, it worked fine until 4.15.0-24-generic #26-Ubuntu, now my network will not resume after suspend.

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

modprobe -r r8169
modprobe -i r8169

does not help.

I am now back to running kernel:

Linux erikkallen-linux 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

which for me does not seem to have the issue

Revision history for this message
Stef Royable (estefantt) wrote :

Same problem here, I've just installed a fresh Ubunbtu 18.04 and updated the system.
My network will not resume after suspend.

I'm new to Linux so if you need more info, please, give me the commands to get them.

Revision history for this message
Ciprian Ionita (t4kt1k4l) wrote :

I have the same problem on Kubuntu 18.04 with the driver r8169, it won't resume after suspend.

Revision history for this message
Parsifal Herzog (parsifal-herzog) wrote :

I have the same problem. Ther was not a problem with Linux Mint 19 Tara (Ubuntu 18.04) and kernel 4.13. Most posts here seem to be associated with Realtek eternet controllers, mine is an Intel I218-LM.

Since kernel 4.15 updates (now automatic on Linux Mint 19) problem occurs. With latest 4.15.0.29-generic, it occurs on every wakeup and on wake from sleep.

Tail of demsg output after wakeup from suspend, and network does not start:

[ 6728.148319] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[ 6728.186196] Bluetooth: hci0: Intel firmware patch completed and activated
[ 6728.358921] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[ 6728.359892] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 6731.311560] e1000e: enp0s25 NIC Link is Up 10 Mbps Full Duplex, Flow Control: Rx/Tx
[ 6731.311564] e1000e 0000:00:19.0 enp0s25: 10/100 speed: disabling TSO
[ 6731.311594] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s25: link becomes ready
[ 6784.144561] e1000e: enp0s25 NIC Link is Down

At this point, I unplug the ethernet cable from the laptop, wait 2 seconds, and re-plug, and this line immediately follows:
[ 6795.074983] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

$ inxi -S -n -N
System: Host: Manjusri Kernel: 4.15.0-29-generic x86_64 bits: 64 Desktop: Xfce 4.12.3
           Distro: Linux Mint 19 Tara
Network: Card-1: Intel Ethernet Connection I218-LM driver: e1000e
           IF: enp0s25 state: up speed: 1000 Mbps duplex: full mac: 68:f7:28:52:e4:08
           Card-2: Intel Wireless 7260 driver: iwlwifi
           IF: wlp3s0 state: down mac: 7c:7a:91:31:dc:bf

Revision history for this message
Vitor (vhsm) wrote :

I have the same problem.

tried

modprobe -r r8169
modprobe -i r8169

does not help.

Revision history for this message
Richard Collier (richcoll) wrote :

I am new to Linux, I had the same problem on Linux Mint 19 Tara Kernel 4.15.0-29 with the driver r8169, wired network unplugged after resume from suspend. I tried various solutions posted here but none worked. I then reverted to Kernel 4.13.0-45 and the network is now connected after resume.

Revision history for this message
DiegoRivera (diego-rivera) wrote :

If unloading-and-reloading the r8169 module solves the problem for you, here's a workaround that does it automatically for you upon resume from suspend:

1) Create a file /etc/systemd/system/fix-r8169.service with the following contents:

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

[Service]
User=root
Type=oneshot
ExecStartPre=/sbin/modprobe -r r8169
ExecStart=/sbin/modprobe r8169
TimeoutSec=0
StandardOutput=syslog

[Install]
WantedBy=suspend.target
##### END FILE #####

2) Execute the following command: sudo systemctl enable fix-r8169.service

Cheers!

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Again, please refer to LP: #1779817 for this new issue.

Revision history for this message
Richard (richard1024) wrote :

I have the same issue as #88 but with a Marvell 88E8040 internal ethernet (Linux Mint 18 Sonya 4.15.0-29). Reverting to 4.13.0-45-generic solved the problem.

Revision history for this message
david (davideltonhall) wrote :

This issue is affecting me. When I wake from suspend my ethernet connection doesn't work, just says "connecting..."

Ubuntu 18.04
4.15.0-29-generic
r8169

This workaround succeeds:

modprobe -r r8169
modprobe -i r8169

$ uname -r
4.15.0-29-generic

$ apt policy linux-image-generic
linux-image-generic:
  Installed: 4.15.0.29.31
  Candidate: 4.15.0.29.31
  Version table:
 *** 4.15.0.29.31 500
        500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     4.15.0.20.23 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

$ lshw -C network
  *-network
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl_nic/rtl8105e-1.fw ip=172.16.0.5 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s

Revision history for this message
slumbergod (slumbergod) wrote :

For some reason my wired connection in 18.04 suddenly stopped working. Wifi was fine. I spend 24 hours trying everything to get it back, including factory resetting the router, changing network cables, and reinstalling Xubuntu many times. After fighting with Acer's buggy secure boot system I managed to get 18.04.1 installed but STILL no wired connection.

I tried removing the driver module and adding it back but still no change.

Then I tried suspending my laptop and waking it up. BINGO. Wired connection came on as it was supposed to.

I don't know what the bug is but it hasn't been fixed and on my hardware at least Wired Connections are broken by default. Only after suspending does it seem to fix itself. Hope that helps devs.

Revision history for this message
elisabeth diana li (elspeth137) wrote :

I'm currently running 4.15.0-30-generic and still having this problem. Reloading the module does not help.

Revision history for this message
Peter Smith (pdo.smith) wrote :

I have the same problem (driver=r8169),Ethernet does not work after resume from suspend.

It works perfectly well with kernel 4.13.0-31. In other words the Ethernet continues to work after resuming from suspend.

But with kernel 4.15.0-32 the Ethernet does not work after resuming from suspend.
I have tried the fix
 modprobe -r r8169
 modprobe -i r8169
but this has no effect.

Revision history for this message
Luis Mandel (luixv) wrote :

I have the same problem.

 *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:04:00.0
       logical name: enp4s0
       version: 06
       serial: 8c:89:a5:a4:74:87
       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=rtl8168e-3_0.0.4 03/27/12 latency=0 link=no multicast=yes port=MII speed=10Mbit/s
       resources: irq:17 ioport:d000(size=256) memory:da104000-da104fff memory:da100000-da103fff
  *-network
       description: Wireless interface
       physical id: 3
       bus info: usb@2:1.6
       logical name: wlx0008ca2fb98d
       serial: 00:08:ca:2f:b9:8d
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=r8712u ip=192.168.178.36 multicast=yes wireless=IEEE 802.11bg

Revision history for this message
Luis Mandel (luixv) wrote :

Hi.
My config is as follows:

lshw -C network
  *-network
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:04:00.0
       logical name: enp4s0
       version: 06
       serial: 8c:89:a5:a4:74:87
       size: 100Mbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8168 driverversion=8.045.08-NAPI duplex=half latency=0 link=no multicast=yes port=twisted pair speed=100Mbit/s
       resources: irq:33 ioport:d000(size=256) memory:da104000-da104fff memory:da100000-da103fff
  *-network
       description: Wireless interface
       physical id: 3
       bus info: usb@2:1.6
       logical name: wlx0008ca2fb98d
       serial: 00:08:ca:2f:b9:8d
       capabilities: ethernet physical wireless
       configuration: broadcast=yes driver=r8712u ip=192.168.178.36 multicast=yes wireless=IEEE 802.11bg
root@mediaserver:/lib/systemd/system-sleep# uname -r
4.15.0-32-generic

And I am affected by this bug.

Revision history for this message
Fatih USTA (fatihusta86) wrote :

"""slumbergod (slumbergod) wrote on 2018-08-03: #93
....
Then I tried suspending my laptop and waking it up. BINGO. Wired connection came on as it was supposed to.
...

"""

I am resolved the same way.

  *-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: 74:e6:e2:xx:xx:xx
       size: 100Mbit/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=full firmware=rtl8411-2_0.0.1 07/08/13 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
       resources: irq:19 ioport:4000(size=256) memory:e3404000-e3404fff memory:e3400000-e3403fff

BIOS Information
        Vendor: Dell Inc.
        Version: A10
        Release Date: 07/18/2014
        Address: 0xE0000
        Runtime Size: 128 kB
        ROM Size: 6656 kB
        Characteristics:
                PCI is supported
                PNP is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                ESCD support is available
                Boot from CD is supported
                Selectable boot is supported
                EDD is supported
                5.25"/360 kB floppy services are supported (int 13h)
                5.25"/1.2 MB floppy services are supported (int 13h)
                3.5"/720 kB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                CGA/mono video services are supported (int 10h)
                ACPI is supported
                USB legacy is supported
                LS-120 boot is supported
                Smart battery is supported
                BIOS boot specification is supported
                Function key-initiated network boot is supported
                Targeted content distribution is supported
        BIOS Revision: 1.0
        Firmware Revision: 1.0

Revision history for this message
Peter Smith (pdo.smith) wrote :

Yesterday, with my daily Ubuntu update, kernel 4.15.0-33 was installed.
Aha, I thought, perhaps now my Ethernet activation after suspension problem is solved.
But no, it was not to be. Kernel 4.15.0-33 does not solve my problem.

And so I have once again reverted to the earlier kernel 4.13.0-31, where everything works as it should and my Ethernet is reliably activated after returning from suspension.

Revision history for this message
Robin Bettridge (robin64) wrote :

Peter Smith - I had the same experience of trying the 4.15.0-33 and it not working for me.
** Try 4.15.0.23 if you would like to be on the 4.15 kernel **

Background:
In my case I am running Mint, but same Ubuntu kernels. It is a desktop PC which is not often suspended so I noticed the problem only a couple of days ago, when already on 4.15.0-30, so tried the 4.15.0-33 which Mint's update manager was offering.. no improvement. The modprobe trick worked and I have a Realtec NIC.

I had seen references to 4.13.0-31 working and also 4.15.0-20, both of which worked for me.

I worked my way up through the following:-
4.15.0-20 resumes
4.15.0-22 resumes
4.15.0-23 resumes
4.15.0-24 does not resume
4.15.0-30 does not resume
4.15.0-33 does not resume
The modprobe treatment worked for the recent -30 and -33, but curiously not on -24. That's probably a symptom of progress.

I thought I experienced a surprising result of going to -24 then back to -23 and the problem reappearing in -23. After a power-off restart all was well again. I had a theory that maybe since all I was doing were OS "restarts" without the PC shutting down the hardware might be holding some state.
I've tried recreating that problem (because it seemed such a dodgy assertion) - but without luck. On the one hand it might be a valid thought that it is very easy to just do restarts between kernels and actually still be holding some unfortunate state in the hardware - OR my bad in accidentally booting the wrong kernel (I've mostly done a uname -a check straight after the boot)

There do seem to have been some inconsistencies in people's experiences, so I wonder if hardware state can be a factor, after all, we are in the area of suspended motherboard h/w
People who know more about Linux initial initialisation of hardware may say I'm talking bo***cks!

Anyway, I'm happy with suspend/resume with 4.15.0-23-generic

Revision history for this message
Julien Richer (julien04) wrote :

4.15.0-33-generic

description: Ordinateur portable
    produit: VORKE V2 (System SKUNumber)
    fabriquant: Intel Corporation
    version: 0.1
    numéro de série: System Serial Number
    bits: 64 bits
    fonctionnalités: smbios-3.0 dmi-3.0 smp vsyscall32
    configuration: boot=normal chassis=laptop family=Kabylake System sku=System SKUNumber uuid=00020003-0004-0005-0006-000700080009
  *-core
       description: Carte mère
       produit: V2 Plus
       fabriquant: Intel Corp.
       identifiant matériel: 0
       version: RVP7
       numéro de série: 1
       emplacement: Part Component
     *-firmware
          description: BIOS
          fabriquant: American Megatrends Inc.
          identifiant matériel: 0
          version: 5.12
          date: 12/08/2017
          taille: 64KiB
          capacité: 15MiB
          fonctionnalités: pci upgrade shadowing cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer acpi usb biosbootspecification uefi

*-network
                description: Ethernet interface
                produit: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
                fabriquant: Realtek Semiconductor Co., Ltd.
                identifiant matériel: 0
                information bus: pci@0000:03:00.0
                nom logique: enp3s0
                version: 07
                numéro de série: 00:e0:4c:d6:1d:e0
                taille: 1Gbit/s
                capacité: 1Gbit/s
                bits: 64 bits
                horloge: 33MHz
                fonctionnalités: 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=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.3.101 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
                ressources: irq:17 portE/S:e000(taille=256) mémoire:df000000-df000fff mémoire:d0000000-d0003fff

And I am affected by this bug.
modprobe does not work here.

Revision history for this message
Andreas Gonell (o-andreas-5) wrote :

$ uname -r
4.15.0-33-generic

$ sudo lshw -C network

  *-network
       Beschreibung: Ethernet interface
       Produkt: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       Hersteller: Realtek Semiconductor Co., Ltd.
       Physische ID: 0
       Bus-Informationen: pci@0000:02:00.0
       Logischer Name: enp2s0
       Version: 03
       Seriennummer: e0:cb:4e:eb:9e:54
       Größe: 1Gbit/s
       Kapazität: 1Gbit/s
       Breite: 64 bits
       Takt: 33MHz
       Fähigkeiten: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       Konfiguration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl_nic/rtl8168d-2.fw ip=192.168.2.50 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       Ressourcen: irq:18 ioport:e800(Größe=256) memory:fafff000-faffffff memory:faff8000-faffbfff memory:fbef0000-fbefffff

LAN disappears when wake up from hibernation.
Script in /lib/systemd/system-sleep/ with

#!/bin/bash
PROGNAME=$(basename "$0")
state=$1
action=$2

if [[ $state == post ]]; then
    modprobe -r r8169 \
    && modprobe -i r8169 \
fi

seems to be a workaround (tested twice).

greetings
andreas

Revision history for this message
Andreas Gonell (o-andreas-5) wrote :

[edit #102]
just tested again: set to hibernation -> wake up again -> LAN is gone...
So, modprobe... doesn't work!

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please refer to LP: #1779817 for regression that caused by this issue's fix.

Revision history for this message
Peter Smith (pdo.smith) wrote :

Kai-Heng Feng,

Success, I tried #1779817:63 and it worked.
This is great, thanks.

Revision history for this message
Ilya Sheershoff (sheershoff) wrote :

Have same RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller and r8169 driver.

$ lspci -knn | grep Eth -A3
01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
    Subsystem: Micro-Star International Co., Ltd. [MSI] RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [1462:7b33]
    Kernel driver in use: r8169
    Kernel modules: r8169

See the difference in controller and driver?

I'm online for an hour since:

try connecting via wifi and
1. sudo apt-get update
2. sudo apt-get install r8168-dkms
 - to install the r8168 kernel driver (suppressing the r8169 driver that came default with the kernel)
3. Reboot the PC
4. Enroll the MOK

Credits: https://askubuntu.com/a/1043584/222703

Revision history for this message
dexter (rekoghllgsuz) wrote :

I have an Ubuntu with kernel 4.15.0-34-generic and network driver sky2.
The network (IP address, DNS server etc.) does *not* resume after a suspend.
So the bug is (still) present.

$ sudo apt-get dist-upgrade
....
## My ubuntu is up-to date. (The backports repo is not enabled.)

$ uname -srvo
Linux 4.15.0-34-generic #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 GNU/Linux

$ ping 87.229.26.159
PING 87.229.26.159 (87.229.26.159) 56(84) bytes of data.
64 bytes from 87.229.26.159: icmp_seq=1 ttl=56 time=7.24 ms
64 bytes from 87.229.26.159: icmp_seq=2 ttl=56 time=9.73 ms

## Now from menu I click on "Suspend" (to ram).

## After a while I press some keys and the system is resuming.

$ ping 87.229.26.159
connect: Network is unreachable
## return code was 2

$ ping index.hu
ping: index.hu: Temporary failure in name resolution
## return code was 2

$ sudo modprobe -r sky2
$ sudo modprobe sky2

$ ping 87.229.26.159
PING 87.229.26.159 (87.229.26.159) 56(84) bytes of data.
64 bytes from 87.229.26.159: icmp_seq=1 ttl=56 time=9.32 ms
64 bytes from 87.229.26.159: icmp_seq=2 ttl=56 time=10.2 ms

$ ping index.hu
PING index.hu (81.0.120.151) 56(84) bytes of data.
64 bytes from smoking-barrel.ficdn2.index.hu (81.0.120.151): icmp_seq=1 ttl=55 time=8.31 ms
64 bytes from smoking-barrel.ficdn2.index.hu (81.0.120.151): icmp_seq=2 ttl=55 time=10.4 ms

$ NetworkManager -V
1.10.6

Revision history for this message
Arthur Peters (amp) wrote :

sky2 is a separate driver. So an issue on sky2 should be reported as a separate issue.

Revision history for this message
RubbelDieCatc (rubbel) wrote :

I can confirm that the fix from DiegoRivera #102 is also functional.
Look here
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772/comments/102

The issue with the r8169 driver exists on other distributions ans kernel versions also.
I use Debian with kernel 4.16.0-2-amd64

18:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
 Subsystem: Micro-Star International Co., Ltd. [MSI] RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
 Flags: bus master, fast devsel, latency 0, IRQ 73
 I/O ports at f000 [size=256]
 Memory at f7604000 (64-bit, non-prefetchable) [size=4K]
 Memory at f7600000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: [40] Power Management version 3
 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [70] Express Endpoint, MSI 01
 Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
 Capabilities: [100] Advanced Error Reporting
 Capabilities: [140] Virtual Channel
 Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
 Capabilities: [170] Latency Tolerance Reporting
 Capabilities: [178] L1 PM Substates
 Kernel driver in use: r8169
 Kernel modules: r8169

Revision history for this message
bitpt (rui-bitpt) wrote :

Linux Fixo 4.18.0-7-generic #8-Ubuntu SMP Tue Aug 28 18:24:42 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

no always after suspend, restart with
sudo modprobe -r r8169
sudo modprobe -i r8169

Revision history for this message
rtimai (rtimai) wrote :

Discovered this bug after a recent (but rarely performed) suspend-resume. My hardware and system info below. Hope this may add to data on affected hardware.

@hp15-ay016nr:~$ lsb_release -d ; uname -r ; gnome-shell --version ; echo $DESKTOP_SESSION
Description: Ubuntu 18.04.1 LTS
4.15.0-36-generic
GNOME Shell 3.28.3
Session: ubuntu (x11)

@hp15-ay016nr:~$ sudo lshw -C network
[sudo] password:
  *-network
       description: Ethernet interface
       product: RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:07:00.0
       logical name: enp7s0
       version: 07
       serial: ec:8e:b5:0d:f6:7e
       size: 100Mbit/s
       capacity: 100Mbit/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 autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8106e-1_0.0.1 06/29/12 ip=192.168.1.64 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
       resources: irq:43 ioport:4000(size=256) memory:c5000000-c5000fff memory:c5100000-c5103fff
  *-network DISABLED
       description: Wireless interface
       product: BCM43142 802.11b/g/n
       vendor: Broadcom Limited
       physical id: 0
       bus info: pci@0000:0d:00.0
       logical name: wlp13s0
       version: 01
       serial: 44:1c:a8:ae:23:11
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=wl0 driverversion=6.30.223.271 (r587334) latency=0 multicast=yes wireless=IEEE 802.11
       resources: irq:16 memory:c3000000-c3007fff

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

rtimai, is it possible for you to file a new bug?

Revision history for this message
Debojoti Chakraborty (chakrabortydebojoti) wrote :

The system is not detecting ethernet connection when the ethernet cable is connected after boot.
The system detects ethernet connection when the ethernet cable is already plugged into the system and system is rebooted.
The system stops detecting ethernet connection after waking up from suspend.

Revision history for this message
Podesta (podesta) wrote :

As suggested, opened a new bug report specific to the sky2 driver: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798921

Revision history for this message
rtimai (rtimai) wrote :

@kaihenfeng: I don't understand. Why should my case be a new bug?

Also, new info: I dist-upgraded to Ubuntu 18.10 Cosmic yesterday, and this bug remains. Wired LAN is not available after suspend-resume in release 18.10 as well. My wife uses an older HP dv6-3012he, and this bug occurs in her upgraded laptop too.

Session info:
Ubuntu 18.10
kernel 4.18.0-10-generic
GNOME Shell 3.30.1
ubuntu (gnome on X11)

The good news is neither of us makes use of suspend, and if the system suspends for any reason, LAN is always restored with a system restart. This is a good-enough workaround for us. We prefer wired LAN to Wi-Fi for both security and performance reasons.

Revision history for this message
rtimai (rtimai) wrote :

This page at a hardware troubleshooter gives a brief description of why resume-after-suspend is prone to loss of connectivity. I think it suggests that this recurring bug may involve any number of factors, such as BIOS/UEFI (updated in 18.10,) networking hardware drivers, grub2, system configuration.

Revision history for this message
rtimai (rtimai) wrote :

https://askleo.com/why-does-my-network-not-work-after-resuming-from-standby/

sorry, forgot to insert the link. No 'edit comment' facility?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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.

Revision history for this message
Tim Passingham (tim-8aw3u04umo) wrote :

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.

Revision history for this message
Tim Passingham (tim-8aw3u04umo) wrote :

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.

Revision history for this message
darren haigh (dazzahaigh) wrote :

also occurs with sky2 driver

Revision history for this message
Oliver Valls (tramuntanal) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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

Revision history for this message
Lope (lopeonline) wrote :

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.

Revision history for this message
Lope (lopeonline) wrote :

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'

Revision history for this message
Vitaliy (librusmc) wrote :

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

Revision history for this message
Chris (azchris) wrote :

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

Revision history for this message
Chris (azchris) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Please test the kernel in -proposed, thanks!

pratik (notpartrick)
Changed in linux (Ubuntu):
assignee: Kai-Heng Feng (kaihengfeng) → nobody
Revision history for this message
Gordon Dracup (gordon-dracup) wrote :

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

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Gordon,
Please file a separate bug report, thanks.

Revision history for this message
wannabeelinux (bas-douma) wrote :

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.

Revision history for this message
HEMANTH KUMAR (hemanth7787-gmail) wrote :

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

Revision history for this message
Aleksey (aleksey-yakovlev) wrote :

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.

Revision history for this message
Roman Valov (reddot) wrote :

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.

Revision history for this message
Ricci Francesco (ricci69) wrote :

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

This bug must be opened again

Changed in linux-kernel-headers (Ubuntu):
status: New → Confirmed
Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Ricci,

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

Revision history for this message
Vladislav Rubtsov (vladikcomper) wrote :

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.

Revision history for this message
John Holcomb (holcomb-technical) wrote :

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

Revision history for this message
Vladislav Rubtsov (vladikcomper) wrote :

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.

Revision history for this message
Vladislav Rubtsov (vladikcomper) wrote :

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.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

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>

Revision history for this message
Manu Schwachsinn (manu-here) wrote :

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

Revision history for this message
Edwin Boersma (princeofnaxos) wrote :

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

Revision history for this message
Jan (klaymendk) wrote :

@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.

Revision history for this message
jc00ke (jesse-jc00ke) wrote :

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.

Revision history for this message
Mark R Wilkins (wilkinsmr) wrote :

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

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Mark,

Please file a separate bug for r8152.

Revision history for this message
JXT (jtipton-x-deactivatedaccount) wrote :

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!

Revision history for this message
JXT (jtipton-x-deactivatedaccount) wrote :

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

Revision history for this message
PJO (lexicographer) wrote :

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?

Revision history for this message
JXT (jtipton-x-deactivatedaccount) wrote :

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

Revision history for this message
JXT (jtipton-x-deactivatedaccount) wrote :

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.

Revision history for this message
Ronaldo (ronaldocouto) wrote :

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.

Revision history for this message
Jon (enviousjag) wrote :

this is still an issue in 2023

Revision history for this message
Pierre C. Dussault (pcduss) wrote :

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).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.