Bug 1312006 - regression - r8169 network driver doesn't work after suspend
regression - r8169 network driver doesn't work after suspend
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
23
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-25 08:55 EST by Jacek Wielemborek
Modified: 2016-12-20 14:01 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 14:01:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The dmesg log (787.69 KB, text/plain)
2016-02-25 08:55 EST, Jacek Wielemborek
no flags Details

  None (edit)
Description Jacek Wielemborek 2016-02-25 08:55:28 EST
Created attachment 1130554 [details]
The dmesg log

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.
Comment 1 Josh Boyer 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?
Comment 2 Jacek Wielemborek 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.
Comment 3 Christian Stadelmann 2016-03-25 08:58:18 EDT
Still happens on 4.4.x kernels.
Comment 4 Christian Stadelmann 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.
Comment 5 Guido Aulisi 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.
Comment 6 Laura Abbott 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.
Comment 7 Christian Stadelmann 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
Comment 8 Christian Stadelmann 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.
Comment 9 Guido Aulisi 2016-09-28 15:50:52 EDT
With kernel 4.7.4-200.fc24.x86_64 this problem seems solved to me.
Comment 10 Guido Aulisi 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
Comment 11 Paul DeStefano 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.
Comment 12 Paul DeStefano 2016-11-16 20:49:54 EST
F24, btw.
Comment 13 Fedora End Of Life 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.
Comment 14 Fedora End Of Life 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.

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