Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1580079
| Summary: | regression - r8169 network driver doesn't work after suspend | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | krinkodot22 |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 31 | CC: | airlied, benedikt, bskeggs, d33tah, eliadevito, ewk, extras-qa, fedora, gansalmon, guido.aulisi, hdegoede, hkallweit1, ichavero, ilochab, itamar, jarodwilson, jcline, jeffj1101, jglisse, john.j5live, jonathan, josef, kernel-maint, krinkodot22, linville, madhu.chinakonda, mchehab, mjg59, nmg921, patdung100+redhat, prd-fedora, steved, zamazan4ik |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel-4.17.2-200.fc28 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1312006 | Environment: | |
| Last Closed: | 2020-05-01 17:59:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
krinkodot22
2018-05-19 21:52:19 UTC
*** Bug 1574334 has been marked as a duplicate of this bug. *** 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! 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. 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. 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. 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 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 That build didn't fix the problem, so I'll try bisecting the kernel. 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. 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".
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. 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! *** Bug 1550701 has been marked as a duplicate of this bug. *** 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. 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 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.) 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 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. 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? 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. Same for me. Fedora 29, kernel 4.19.8-300. Also reproduced on 4.19.6 Reopening per comments #19 through comment #21. 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 *********** 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. kernel 4.20.6-200.fc29.x86_64, problem still present kernel 4.20.10-200.fc29.x86_64, problem still present 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.
(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. 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. 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! (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 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 *********** 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. (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 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 *********** 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. 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. 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. 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. (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. |