Bug 1580079 - regression - r8169 network driver doesn't work after suspend
Summary: regression - r8169 network driver doesn't work after suspend
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 31
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1550701 1574334 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-19 21:52 UTC by krinkodot22
Modified: 2020-05-01 17:59 UTC (History)
33 users (show)

Fixed In Version: kernel-4.17.2-200.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1312006
Environment:
Last Closed: 2020-05-01 17:59:48 UTC
Type: Bug


Attachments (Terms of Use)

Description krinkodot22 2018-05-19 21:52:19 UTC
+++ This bug was initially created as a clone of Bug #1312006 +++

Description of problem:

Kernel has a regression that prevents r8169 driver from working after a suspend-to-ram.

Version-Release number of selected component (if applicable):

4.2.6-301.fc23.x86_64 #1 SMP

How reproducible:

Everytime

Steps to Reproduce:
1. Boot the kernel
2. Notice that the network works
3. Suspend to ram
4. Notice that network doesn't work

Actual results:

I attach the dmesg log.

Expected results:

Network works as before.

Additional info:

This used to work in previous kernels - a regression appeared quite recently.

--- Additional comment from Josh Boyer on 2016-02-25 09:02:05 EST ---

The 4.2.y kernel is rather old on F23 at this point.  It has already been rebased to 4.4.2.  Does this problem happen on the latest 4.4.2 kernel available?

--- Additional comment from Jacek Wielemborek on 2016-02-26 11:12:06 EST ---

@Josh Boyer:

It still fails on "Linux d33tah-pc 4.3.5-300.fc23.x86_64 #1 SMP Mon Feb 1 03:18:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux". This is the latest available in my F23 repo.

--- Additional comment from Christian Stadelmann on 2016-03-25 08:58:18 EDT ---

Still happens on 4.4.x kernels.

--- Additional comment from Christian Stadelmann on 2016-03-25 09:20:59 EDT ---

Possible duplicates: bug #1282254 and bug #1289499

There was no change in the r8169.c on kernel upstream, if you diff the git logs:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/net/ethernet/realtek/r8169.c?h=v4.2.6
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/drivers/net/ethernet/realtek/r8169.c?h=v4.2.3

No directly related changes in fedora kernel git either. Seems like something outside r8169.c broke it.

--- Additional comment from Guido Aulisi on 2016-08-04 04:10:25 EDT ---

It still happens in Fedora 24 with kernel 4.6.4-301.fc24.x86_64.
After resuming the driver reports link down, even ethtool reports link down.
Unloading and reloading r8168 module makes link up again.

--- Additional comment from Laura Abbott on 2016-09-23 15:44:36 EDT ---

*********** MASS BUG UPDATE **************
 
We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs.
 
Fedora 23 has now been rebased to 4.7.4-100.fc23.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.
 
If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25.
 
If you experience different issues, please open a new bug report for those.

--- Additional comment from Christian Stadelmann on 2016-09-23 17:10:29 EDT ---

NetworkManager still shows connection problems after suspend, but I haven't managed to reproduce a connection loss on suspend by trying 4 times. I disabled my workaround and will report back in case the issue is happening again.

Running kernel-4.7.4-200.fc24.x86_64

--- Additional comment from Christian Stadelmann on 2016-09-28 15:05:54 EDT ---

(In reply to Christian Stadelmann from comment #7)
> NetworkManager still shows connection problems after suspend, but I haven't
> managed to reproduce a connection loss on suspend by trying 4 times. I
> disabled my workaround and will report back in case the issue is happening
> again.
> 
> Running kernel-4.7.4-200.fc24.x86_64

After a week of running without my previous workaround the issue stays the same: Network connection doesn't drop any more, but NetworkManager still shows a question mark on its gnome-shell icon.

--- Additional comment from Guido Aulisi on 2016-09-28 15:50:52 EDT ---

With kernel 4.7.4-200.fc24.x86_64 this problem seems solved to me.

--- Additional comment from Guido Aulisi on 2016-11-08 07:58:44 EST ---

Today I had this problem once again with kernel 4.8.4-200.fc24.x86_64.

dmesg:
[11828.743479] wlp7s0: deauthenticating from 08:17:35:9c:b8:32 by local choice (Reason: 3=DEAUTH_LEAVING)
[11830.605427] PM: Syncing filesystems ... done.
[11831.320986] PM: Preparing system for sleep (mem)
[11831.321261] Freezing user space processes ... (elapsed 0.002 seconds) done.
[11831.323706] Double checking all user space processes after OOM killer disable... (elapsed 0.000 seconds) 
[11831.323885] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[11831.325307] PM: Suspending system (mem)
[11831.325407] Suspending console(s) (use no_console_suspend to debug)
[11831.325834] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[11831.412677] sd 0:0:0:0: [sda] Stopping disk
[11831.799927] PM: suspend of devices complete after 474.375 msecs
[11831.812778] PM: late suspend of devices complete after 12.839 msecs
[11831.814104] r8169 0000:13:00.0: System wakeup enabled by ACPI
[11831.814275] ehci-pci 0000:00:1d.0: System wakeup enabled by ACPI
[11831.814405] ehci-pci 0000:00:1a.0: System wakeup enabled by ACPI
[11831.825790] PM: noirq suspend of devices complete after 13.007 msecs
[11831.826232] ACPI: Preparing to enter system sleep state S3
[11831.845758] ACPI : EC: EC stopped
[11831.845759] PM: Saving platform NVS memory
[11831.846652] Disabling non-boot CPUs ...
[11831.848834] smpboot: CPU 1 is now offline
[11831.850695] smpboot: CPU 2 is now offline
[11831.852482] smpboot: CPU 3 is now offline
[11831.854226] ACPI: Low-level resume complete
[11831.854287] ACPI : EC: EC started
[11831.854288] PM: Restoring platform NVS memory
[11831.855494] Enabling non-boot CPUs ...
[11831.855532] x86: Booting SMP configuration:
[11831.855533] smpboot: Booting Node 0 Processor 1 APIC 0x1
[11831.858008]  cache: parent cpu1 should not be sleeping
[11831.858446] CPU1 is up
[11831.858507] smpboot: Booting Node 0 Processor 2 APIC 0x2
[11831.861760]  cache: parent cpu2 should not be sleeping
[11831.862210] CPU2 is up
[11831.862251] smpboot: Booting Node 0 Processor 3 APIC 0x3
[11831.865201]  cache: parent cpu3 should not be sleeping
[11831.865681] CPU3 is up
[11831.873937] ACPI: Waking up from system sleep state S3
[11831.897163] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI
[11831.897650] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI
[11831.897732] PM: noirq resume of devices complete after 13.357 msecs
[11831.898055] PM: early resume of devices complete after 0.297 msecs
[11831.898511] r8169 0000:13:00.0: System wakeup disabled by ACPI
[11831.899434] ath: phy0: ASPM enabled: 0x43
[11831.908570] sd 0:0:0:0: [sda] Starting disk
[11832.029575] r8169 0000:13:00.0 enp19s0: link down
[11832.120376] usb 1-1.5: reset full-speed USB device number 5 using ehci-pci
[11832.177681] rtc_cmos 00:01: System wakeup disabled by ACPI
[11832.198677] usb 1-1.5: device firmware changed
[11832.199199] PM: resume of devices complete after 301.151 msecs
[11832.199530] PM: Finishing wakeup.
[11832.199532] Restarting tasks ... 
[11832.207570] usb 1-1.5: USB disconnect, device number 5
[11832.210301] done.
[11832.226371] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[11832.245956] ata4.00: configured for UDMA/66
[11832.279331] usb 1-1.5: new full-speed USB device number 6 using ehci-pci
[11832.358204] usb 1-1.5: New USB device found, idVendor=0489, idProduct=e027
[11832.358211] usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[11832.668182] usb 1-1.5: USB disconnect, device number 6
[11833.352313] usb 1-1.5: new full-speed USB device number 7 using ehci-pci
[11833.431741] usb 1-1.5: New USB device found, idVendor=0cf3, idProduct=3005
[11833.431748] usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[11833.503967] video LNXVIDEO:01: Restoring backlight state
[11834.535570] i8042: Can't write CTR while closing AUX port
[11834.849230] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[11834.873884] ata1.00: configured for UDMA/133
[11835.061405] i8042: Can't reactivate AUX port
[11835.495124] IPv6: ADDRCONF(NETDEV_UP): enp19s0: link is not ready
[11835.625261] r8169 0000:13:00.0 enp19s0: link down
[11835.625341] IPv6: ADDRCONF(NETDEV_UP): enp19s0: link is not ready
[11835.626622] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[11835.646703] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[11835.690577] IPv6: ADDRCONF(NETDEV_UP): wlp7s0: link is not ready
[11836.474269] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input15
[11837.613049] wlp7s0: authenticate with 08:17:35:9c:b8:32
[11837.631382] wlp7s0: send auth to 08:17:35:9c:b8:32 (try 1/3)
[11837.632840] wlp7s0: authenticated
[11837.634631] wlp7s0: associate with 08:17:35:9c:b8:32 (try 1/3)
[11837.637739] wlp7s0: RX AssocResp from 08:17:35:9c:b8:32 (capab=0x431 status=0 aid=96)
[11837.637893] wlp7s0: associated
[11837.637968] IPv6: ADDRCONF(NETDEV_CHANGE): wlp7s0: link becomes ready
[11837.645921] ath: EEPROM regdomain: 0x817c
[11837.645924] ath: EEPROM indicates we should expect a country code
[11837.645926] ath: doing EEPROM country->regdmn map search
[11837.645927] ath: country maps to regdmn code: 0x37
[11837.645929] ath: Country alpha2 being used: IT
[11837.645930] ath: Regpair used: 0x37
[11837.645932] ath: regdomain 0x817c dynamically updated by country IE
[11837.692952] wlp7s0: Limiting TX power to 17 dBm as advertised by 08:17:35:9c:b8:32
[11838.148302] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input17

--- Additional comment from Paul DeStefano on 2016-11-16 20:47:23 EST ---

I don't remember this from February, but this has happened to me three times in the last two days after upgrading to 4.8, too.  My log looks pretty similar.

--- Additional comment from Paul DeStefano on 2016-11-16 20:49:54 EST ---

F24, btw.

--- Additional comment from Fedora End Of Life on 2016-11-24 10:45:47 EST ---

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Fedora End Of Life on 2016-12-20 14:01:36 EST ---

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--- Additional comment from  on 2018-05-05 18:03:01 EDT ---

This issue is still present on Fedora 27 and Fedora 28. See bug 1574334. Should this bug be reopened or cloned? Or should bug 1574334 be used to track this for F28?

Comment 1 krinkodot22 2018-05-19 21:54:47 UTC
*** Bug 1574334 has been marked as a duplicate of this bug. ***

Comment 2 Jeremy Cline 2018-05-30 20:25:53 UTC
Hi,

Can you confirm if this is still present in the latest stable kernel? There was a power management related fix for the r8169 driver in v4.16.10. Thanks!

Comment 3 krinkodot22 2018-05-31 05:12:15 UTC
The same issue still happens to me even after updating my system.

There is a small improvement, though: when restarting r8169, my wired connection resumes much more quickly than it did before. Up until a few days ago, it could take a minute or two to resume. Now, it comes back in under 5 seconds.

Comment 4 Jeremy Cline 2018-05-31 16:16:59 UTC
Thanks for confirming it's a separate issue.

The subject indicates it's a regression. Did it ever work for you or are you going by the old bugzilla? If it did work, what was the last kernel version where it worked?

Tracking down what kernel version introduced the regression would be a good first step. If it never worked for you it'd be good to confirm that, as the original bug claimed, v4.7.4 works. If it does, try newer 4.x kernels to see which major kernel release introduced the regression. You can find all the kernels built for Fedora at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 and you can change how many kernels you have installed by changing installonly_limit in /etc/dnf/dnf.conf.

Comment 5 krinkodot22 2018-06-03 03:49:26 UTC
Thanks for the advice. Using kernel-4.7.4-200.fc24.x86_64 does fix the problem for me: I'm able to suspend & wake up without losing a wired connection. Next, I'll look for the earliest kernel version where the issue comes back.

Comment 6 krinkodot22 2018-06-03 07:08:11 UTC
The latest kernel version that *doesn't* hit this issue for me is 4.14.18: https://koji.fedoraproject.org/koji/buildinfo?buildID=1030043

The earliest version that *does* hit the issue is 4.15.0: https://koji.fedoraproject.org/koji/buildinfo?buildID=1021748

Comment 7 Jeremy Cline 2018-06-04 15:53:07 UTC
Excellent, so the problem got introduced in between 4.15 and 4.16. There's actually several power management changes to r8169 in 4.16 which might be responsible (and, of course, the problem could be due to a change outside the driver itself). I've reverted one that sounds slightly more likely to me than the others[0]. If that build doesn't fix the problem, it'd very helpful if you bisected[1] the kernel to track down the issue.


[0] https://koji.fedoraproject.org/koji/taskinfo?taskID=27416472
[1] https://docs.fedoraproject.org/quick-docs/en-US/kernel/troubleshooting.html#bisecting-the-kernel

Comment 8 krinkodot22 2018-06-05 04:24:09 UTC
That build didn't fix the problem, so I'll try bisecting the kernel.

Comment 9 krinkodot22 2018-06-15 04:51:37 UTC
I'm in the process of bisecting the kernel, and ran into a few difficulties along the way. Maybe it would be a good idea to address some of these issues on the Fedora Quick Docs page to save time for others in the future.

-When using fedpkg to build a kernel rpm, using 'git checkout origin/f<version>' won't work unless it creates a local branch based off of the remote branch. When in "detached HEAD" mode, fedpkg builds will fail with "Unable to find remote branch".

-Using "fedpkg local" to rebuild the 4.15 kernel, it fails with an error that gives the suggestion to "use --release". Using "fedpkg --release f28 local" works. I assume this is because fedpkg needs to know which Fedora version to create a package for, and that the default is rawhide. Is this correct? Either way, consider mentioning the --release option on the Fedora Docs page to assist those building older kernel versions.

-Also when using "fedpkg --release f28 local", although it allows a build to happen, fedpkg ultimately fails with an error of "No build ID note found in <path>". I'm not entirely sure why that is, but I did some websearching for possible solutions that I'll try out. This error is also something that could be addressed in the Fedora Docs page.

-When building vanilla kernels, perhaps the Fedora Docs guide should clarify whether the dependencies for using fedpkg are enough to build vanilla kernels. I wasn't sure, so I just downloaded most of the dependencies mentioned on the Linux kernel help documentation.

-Also for vanilla kernels, maybe it should be mentioned that gcc 8.0 has a bug that prevents even relatively recent kernel versions from being built (https://www.systutorials.com/linux-kernels/488816/objtool-perf-fix-gcc-8-wrestrict-error-linux-4-14-39/#). gcc 7.4 works fine.


As a side note, how much time should ccache save on rebuilds? I've reran builds for the same kernel version a few times with fedpkg, and each build seems to take just as long as the last.

Comment 10 krinkodot22 2018-06-15 05:01:50 UTC
Also, with fedpkg builds, the kernel appears to be built twice ("make bzImage" & "make modules" both get called twice). Is that expected?

If it makes a difference, that happens whether or not I disable debugging options with "make release".

Comment 11 Benedikt Gollatz 2018-06-16 18:51:50 UTC
According to the corresponding Ubuntu bug on Launchpad (<https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1752772>) the responsible commit is bc976233a872c0f20f018fb1e89264a541584e25. I've just verified this on my system: if I build 4.16.14-200.fc27.x86_64 with that commit reverted, I can continue to use my network adapter after suspend/resume without having to reload the r8169 driver.

Comment 12 Jeremy Cline 2018-06-18 20:44:34 UTC
krinkodot22, when bisecting you just build the kernel with make. Obviously the documentation shouldn't have led you astray there. Was it that the bisecting docs linked to the "building a custom kernel" docs that led you to that? I'd definitely like to improve those docs.

Thanks for the pointer Benedikt, it sounds like it got fixed somewhere in the 4.17 development cycle. Fedora 28 is getting rebased to 4.17 this week, when the update is pushed to updates-testing can you both test it and make sure that fixes things? Thanks!

Comment 13 Beniamino Galvani 2018-06-21 08:41:40 UTC
*** Bug 1550701 has been marked as a duplicate of this bug. ***

Comment 14 Benedikt Gollatz 2018-06-21 11:07:36 UTC
I have upgraded the affected system to F28 and installed kernel-4.17.2-200.fc28.x86_64 from updates-testing, which indeed seems to have fixed the problem.

Comment 15 Fedora Update System 2018-06-21 14:00:11 UTC
kernel-4.17.2-200.fc28 kernel-tools-4.17.2-200.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2c6bd93875

Comment 16 krinkodot22 2018-06-22 03:50:30 UTC
The 4.17.2 update fixes the problem for me too. Benedikt, thanks for your helpful info!

Also, if it makes a difference, when bisecting vanilla kernels, I found that my computer hits the bug somewhere between 4.15-rc8 and 4.15-rc9 (I didn't directly reach a breaking commit, as many builds failed to boot with each taking a half hour to be compiled, and seeing that a fix is in place I decided to stop :] ). But that's strange, since the Ubuntu bug showed that rc6 introduced the breaking commit, not rc9. Either way, 4.17.2 fixes the problem anyways, so it's probably not a big deal.

(PS @ Jeremy: I was using 'make' to build the vanilla kernel, and fedpkg to build Fedora kernel RPMs. My main confusion came from not being sure whether the setup for building RPMs was also needed to set up building the vanilla kernel, and from some of the technical issues I ran into.)

Comment 17 Jeremy Cline 2018-06-22 13:21:09 UTC
Ahhh, okay. You shouldn't need to build the Fedora kernel RPMs since all the kernel builds are stored permanently in Koji[0]. I should add a section to the documentation that covers that.

[0] https://koji.fedoraproject.org/koji/packageinfo?packageID=8

Comment 18 Fedora Update System 2018-06-23 20:47:47 UTC
kernel-4.17.2-200.fc28, kernel-tools-4.17.2-200.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 19 Alexander Zaitsev 2018-07-08 12:05:39 UTC
Kernels 4.17.3 and 4.18-rc3 - problem still presents and fix with load/unload -r8169 doesn't work on these kermels. Workaround with modprobe waorks only on 4.16. I temporary disabled kernel update and wait for permanent fix :)

Do you need any additional information?

Comment 20 Nikita Goncharuk 2018-11-17 16:49:58 UTC
Problem still persist on Fedora 29 and kernel 4.18 (4.18.18-300.fc29.x86_64 and earlier)

I have to 

modprobe -r r8169
modprobe -i r8169

after each resume from suspend.

Comment 21 Alexander Zaitsev 2018-12-12 19:06:31 UTC
Same for me. Fedora 29, kernel 4.19.8-300. Also reproduced on 4.19.6

Comment 22 Christian Stadelmann 2018-12-12 21:50:27 UTC
Reopening per comments #19 through comment #21.

Comment 23 Nikita Goncharuk 2018-12-28 06:22:53 UTC
Now I can to get back my wired connection with 'systemctl restart NetworkManager'

Kernel  4.19.10-300.fc29.x86_64
NetworkManager  1.12.6-3.fc29

Comment 24 Justin M. Forbes 2019-01-29 16:13:25 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs.

Fedora 29 has now been rebased to 4.20.5-200.fc29.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 25 Nikita Goncharuk 2019-02-06 06:48:43 UTC
kernel 4.20.6-200.fc29.x86_64, problem still present

Comment 26 Licia Leanza 2019-02-22 18:34:12 UTC
kernel 4.20.10-200.fc29.x86_64, problem still present

Comment 27 jeffj1101 2019-05-02 19:18:31 UTC
Problem persists on F29, Kernel 5.0.9-200.fc29.x86_64, NetworkManager.x86_64 ver: 1:1.12.6-5.fc29 

modprobe r8169 resolves the problem. 

Network adapter is:

Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7721]
        Kernel driver in use: r8169
        Kernel modules: r8169

Network is named as enp2s0 as default at install.

Comment 28 jeffj1101 2019-05-02 19:22:06 UTC
(In reply to jeffj1101 from comment #27)
> Problem persists on F29, Kernel 5.0.9-200.fc29.x86_64, NetworkManager.x86_64
> ver: 1:1.12.6-5.fc29 
> 
> Temporary solution is : modprobe r8169 
> 
> Network adapter is:
> 
> Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev
> 0c)
>         Subsystem: Micro-Star International Co., Ltd. [MSI] Device
> [1462:7721]
>         Kernel driver in use: r8169
>         Kernel modules: r8169
> 
> Network is named as enp2s0 as default at install.

Comment 29 Licia Leanza 2019-05-03 16:48:02 UTC
I verified that after a resume, with no ethernet due to this problem, if you wait for a while (around an hour) the card returns available and its connection too, spontaneously, whithout doing anything at all!!!

Lukily "modprobe -i r8169" works for me too.

Comment 30 jeffj1101 2019-05-06 21:53:53 UTC
I can confirm this issue is still present on F30. The problem is with the kernel not loading r8169 module when resuming from a suspend. The network link stays down. Therefore I get no network after resuming from a suspend (using Ethernet). Running 'modprobe r8169' solves the problem. Below is a snippet from the journalctl. 

Fedora 30
Kernel: 5.0.11-300.fc30.x86_64
NetworkManager.x86_64 ver: 1:1.16.0-1.fc30



May 06 22:02:25  avahi-daemon[765]: Joining mDNS multicast group on interface enp2s0.IPv6 with address <IP ADDRSS REMOVED FOR THIS BUG REPORT>.
May 06 22:02:25  NetworkManager[869]: <info>  [1557176545.8710] manager: sleep: wake requested (sleeping: yes  enabled: yes)
May 06 22:02:25  avahi-daemon[765]: Registering new address record for <IP ADDRSS REMOVED FOR THIS BUG REPORT> on enp2s0.*.
May 06 22:02:25  NetworkManager[869]: <info>  [1557176545.8711] device (enp2s0): state change: activated -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
May 06 22:02:25  avahi-daemon[765]: Withdrawing address record for <IP ADDRSS REMOVED FOR THIS BUG REPORT> on enp2s0.
May 06 22:02:25  NetworkManager[869]: <info>  [1557176545.8769] dhcp4 (enp2s0): canceled DHCP transaction, DHCP client pid 1108
May 06 22:02:25  avahi-daemon[765]: Leaving mDNS multicast group on interface enp2s0.IPv6 with address <IP ADDRSS REMOVED FOR THIS BUG REPORT>.
May 06 22:02:25  NetworkManager[869]: <info>  [1557176545.8769] dhcp4 (enp2s0): state changed bound -> done
May 06 22:02:25  avahi-daemon[765]: Interface enp2s0.IPv6 no longer relevant for mDNS.
May 06 22:02:25  NetworkManager[869]: <info>  [1557176545.8779] dhcp6 (enp2s0): canceled DHCP transaction
May 06 22:02:25  dnsmasq[1089]: reading /etc/resolv.conf
May 06 22:02:25  NetworkManager[869]: <info>  [1557176545.8779] dhcp6 (enp2s0): state changed terminated -> done
May 06 22:02:25  dnsmasq[1089]: using nameserver <IP ADDRSS REMOVED FOR THIS BUG REPORT>
May 06 22:02:25  systemd[1]: Stopped target Suspend.
May 06 22:02:25  dnsmasq[1089]: no servers found in /etc/resolv.conf, will retry
May 06 22:02:25  NetworkManager[869]: <info>  [1557176545.8973] manager: NetworkManager state is now CONNECTED_GLOBAL
May 06 22:02:25  NetworkManager[869]: <info>  [1557176545.9121] device (enp2s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed')
May 06 22:02:25  kernel: Generic PHY r8169-200:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE)
May 06 22:02:25  systemd[1]: Starting Network Manager Script Dispatcher Service...
May 06 22:02:25  systemd[1]: Stopped target Bluetooth.
May 06 22:02:25  systemd[1]: Reached target Bluetooth.
May 06 22:02:26  kernel: r8169 0000:02:00.0 enp2s0: Link is Down
May 06 22:02:26  NetworkManager[869]: <warn>  [1557176546.0404] dns-sd-resolved[0x558e2e723420]: Failed: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer.
May 06 22:02:26  NetworkManager[869]: <warn>  [1557176546.0404] dns-sd-resolved[0x558e2e723420]: Failed: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer.
May 06 22:02:26  NetworkManager[869]: <warn>  [1557176546.0405] dns-sd-resolved[0x558e2e723420]: Failed: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer.
May 06 22:02:26  NetworkManager[869]: <warn>  [1557176546.0405] dns-sd-resolved[0x558e2e723420]: Failed: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer.
May 06 22:02:27  kernel: r8169 0000:02:00.0 enp2s0: Link is Up - 100Mbps/Full - flow control off
May 06 22:02:27  kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0: link becomes ready
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6671] device (enp2s0): carrier: link connected
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6678] device (enp2s0): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6694] policy: auto-activating connection 'enp2s0' (<IP ADDRSS REMOVED FOR THIS BUG REPORT>)
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6709] device (enp2s0): Activation: starting connection 'enp2s0' (<IP ADDRSS REMOVED FOR THIS BUG REPORT>)
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6711] device (enp2s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6721] manager: NetworkManager state is now CONNECTING
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6724] device (enp2s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
May 06 22:02:27  audit: NETFILTER_CFG table=raw family=2 entries=28
May 06 22:02:27  audit: NETFILTER_CFG table=mangle family=2 entries=43
May 06 22:02:27  audit: NETFILTER_CFG table=nat family=2 entries=58
May 06 22:02:27  audit: NETFILTER_CFG table=filter family=2 entries=107
May 06 22:02:27  audit: NETFILTER_CFG table=raw family=10 entries=30
May 06 22:02:27  audit: NETFILTER_CFG table=mangle family=10 entries=42
May 06 22:02:27  audit: NETFILTER_CFG table=nat family=10 entries=53
May 06 22:02:27  audit: NETFILTER_CFG table=filter family=10 entries=98
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6887] device (enp2s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6892] dhcp4 (enp2s0): activation: beginning transaction (timeout in 45 seconds)
May 06 22:02:27  NetworkManager[869]: <info>  [1557176547.6915] dhcp4 (enp2s0): dhclient started with pid 1460
May 06 22:02:27  avahi-daemon[765]: Joining mDNS multicast group on interface enp2s0.IPv6 with address <IP ADDRSS REMOVED FOR THIS BUG REPORT>.
May 06 22:02:27  avahi-daemon[765]: New relevant interface enp2s0.IPv6 for mDNS.
May 06 22:02:27  avahi-daemon[765]: Registering new address record for <IP ADDRSS REMOVED FOR THIS BUG REPORT> on enp2s0.*.
May 06 22:02:27  dhclient[1460]: DHCPREQUEST on enp2s0 to <IP ADDRSS REMOVED FOR THIS BUG REPORT> port 67 (xid=0x919f5a7e)
May 06 22:02:28  kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
May 06 22:02:28  kernel: ata1.00: configured for UDMA/100
May 06 22:02:28  systemd[1]: sssd-kcm.service: Succeeded.
May 06 22:02:28  audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-kcm comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 06 22:02:28  systemd[1]: Starting SSSD Kerberos Cache Manager...
May 06 22:02:28  ModemManager[776]: <info>  Couldn't check support for device '/sys/devices/pci0000:00/0000:00:03.1/0000:02:00.0': not supported by any plugin
May 06 22:02:28  systemd[1]: Started Load/Save RF Kill Switch Status.
May 06 22:02:28  audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
May 06 22:02:28  audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res>
May 06 22:02:28  nm-dispatcher[1450]: req:1 'down' [enp2s0]: new request (3 scripts)
May 06 22:02:28  systemd[1]: Started Network Manager Script Dispatcher Service.
May 06 22:02:28  nm-dispatcher[1450]: req:1 'down' [enp2s0]: start running ordered scripts...
May 06 22:02:29  chronyd[782]: Forward time jump detected!

Comment 31 Heiner Kallweit 2019-05-07 17:59:26 UTC
(In reply to jeffj1101 from comment #30)
> I can confirm this issue is still present on F30. The problem is with the
> kernel not loading r8169 module when resuming from a suspend. The network
> link stays down. Therefore I get no network after resuming from a suspend
> (using Ethernet). Running 'modprobe r8169' solves the problem. Below is a
> snippet from the journalctl. 
> 
> Fedora 30
> Kernel: 5.0.11-300.fc30.x86_64
> NetworkManager.x86_64 ver: 1:1.16.0-1.fc30
> 
Suspending doesn't unload a kernel module except some userspace tool does this intentionally. So it seems to more likely an issue with this userspace tool than with the kernel.
For your reference here a syslog from a S3 suspend / resume cycle.

[176286.873886] PM: suspend entry (deep)
[176286.901437] Filesystems sync: 0.027 seconds
[176286.908193] Freezing user space processes ... (elapsed 0.002 seconds) done.
[176286.910752] OOM killer disabled.
[176286.910769] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[176286.912958] printk: Suspending console(s) (use no_console_suspend to debug)
[176286.915201] r8169 0000:03:00.0 enp3s0: Link is Down
[176286.921675] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[176286.922004] sd 0:0:0:0: [sda] Stopping disk
[176287.014845] ACPI: Preparing to enter system sleep state S3
[176287.015144] ACPI Debug:  "SIOS"
[176287.017978] PM: Saving platform NVS memory
[176287.018099] Disabling non-boot CPUs ...
[176287.029070] smpboot: CPU 1 is now offline
[176287.037095] smpboot: CPU 2 is now offline
[176287.041457] smpboot: CPU 3 is now offline
[176287.045991] ACPI: Low-level resume complete
[176287.046275] PM: Restoring platform NVS memory
[176287.053521] Enabling non-boot CPUs ...
[176287.054144] x86: Booting SMP configuration:
[176287.054201] smpboot: Booting Node 0 Processor 1 APIC 0x2
[176287.062647] CPU1 is up
[176287.062958] smpboot: Booting Node 0 Processor 2 APIC 0x4
[176287.068133] microcode: sig=0x506c9, pf=0x1, revision=0x2e
[176287.072805] microcode: updated to revision 0x36, date = 2018-09-14
[176287.073655] CPU2 is up
[176287.073885] smpboot: Booting Node 0 Processor 3 APIC 0x6
[176287.077897] microcode: sig=0x506c9, pf=0x1, revision=0x36
[176287.079050] CPU3 is up
[176287.084429] ACPI: Waking up from system sleep state S3
[176287.087713] ACPI Debug:  "SIOW"
[176287.128227] sd 0:0:0:0: [sda] Starting disk
[176287.202510] r8169 0000:03:00.0 enp3s0: Link is Down
[176287.399052] usb 1-6: reset high-speed USB device number 3 using xhci_hcd
[176287.441489] ata2: SATA link down (SStatus 4 SControl 300)
[176287.595583] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[176287.597817] ata1.00: configured for UDMA/133
[176287.619749] OOM killer enabled.
[176287.619790] Restarting tasks ... done.
[176287.623476] video LNXVIDEO:00: Restoring backlight state
[176287.640616] PM: suspend exit
[176290.328354] r8169 0000:03:00.0 enp3s0: Link is Up - 1Gbps/Full - flow control rx/tx

Comment 32 Heiner Kallweit 2019-06-03 12:29:04 UTC
Issue description matches a problem with certain chip versions. You could check whether the following fixes the issue for you.
This fix/workaround is queued up for -stable.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/net/ethernet/realtek/r8169.c?h=next-20190603&id=59715171fbd0172a579576f46821031800a63bc5

Comment 33 Justin M. Forbes 2019-08-20 17:41:17 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.2.9-200.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

Comment 34 Nikita Goncharuk 2019-08-28 09:49:07 UTC
(In reply to Justin M. Forbes from comment #33)
> *********** MASS BUG UPDATE **************
> 
> We apologize for the inconvenience.  There are a large number of bugs to go
> through and several of them have gone stale.  Due to this, we are doing a
> mass bug update across all of the Fedora 30 kernel bugs.
> 
> Fedora 30 has now been rebased to 5.2.9-200.fc30.  Please test this kernel
> update (or newer) and let us know if you issue has been resolved or if it is
> still present with the newer kernel.
> 
> If you have moved on to Fedora 31, and are still experiencing this issue,
> please change the version to Fedora 31.
> 
> If you experience different issues, please open a new bug report for those.

Unfortunately this issue was not fixed. It takes about 30 seconds or more to reconnect to wired network after resume from suspend and sometimes I have to restart NetworkManager manually via systemctl because it do not reconnecting too long (or probably do not reconnecting at all).

$ uname -r
5.2.9-200.fc30.x86_64

$ lspci -k | grep -A3 Ethernet
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
	Subsystem: Hewlett-Packard Company Device 1944
	Kernel driver in use: r8169
	Kernel modules: r8169

Comment 35 krinkodot22 2019-10-22 04:10:27 UTC
This problem hasn't occurred for me in quite some time. Waking up from suspend has the wired connection come back almost instantaneously.

$ uname -r
5.3.6-200.fc30.x86_64

~$ lspci -k | grep -A3 Ethernet
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
	Subsystem: ASUSTeK Computer Inc. Device 200f
	Kernel driver in use: r8169
	Kernel modules: r8169

Comment 36 Justin M. Forbes 2020-03-03 16:33:40 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.5.7-100.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

Comment 37 krinkodot22 2020-03-09 03:47:19 UTC
This no longer happens to me, but judging from other comments posted here, the problem isn't fully fixed.
Nikita, I'm giving you my NEEEDINFO to confirm/deny if you're still hittng this problem.

Comment 38 Nikita Goncharuk 2020-03-09 10:08:40 UTC
I am on Fedora 31 now and I do not have this problem. But I can't remember when it was fixed and if I did anything to fix it.

Comment 39 Ben Cotton 2020-04-30 20:22:14 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 40 Christian Stadelmann 2020-05-01 17:59:48 UTC
(In reply to Nikita Goncharuk from comment #38)
> I am on Fedora 31 now and I do not have this problem. But I can't remember
> when it was fixed and if I did anything to fix it.

I am on Fedora 31 too and I don't see this problem any more either. I'm not 100% sure but I think I don't have any workaround in place.


Note You need to log in before you can comment on or make changes to this bug.