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 1312006 - regression - r8169 network driver doesn't work after suspend
Summary: regression - r8169 network driver doesn't work after suspend
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 23
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-25 13:55 UTC by Jacek Wielemborek
Modified: 2018-05-05 22:03 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1580079 (view as bug list)
Environment:
Last Closed: 2016-12-20 19:01:36 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
The dmesg log (deleted)
2016-02-25 13:55 UTC, Jacek Wielemborek
no flags Details

Description Jacek Wielemborek 2016-02-25 13:55:28 UTC
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 14:02:05 UTC
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 16:12:06 UTC
@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 12:58:18 UTC
Still happens on 4.4.x kernels.

Comment 4 Christian Stadelmann 2016-03-25 13:20:59 UTC
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 08:10:25 UTC
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 19:44:36 UTC
*********** 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 21:10:29 UTC
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 19:05:54 UTC
(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 19:50:52 UTC
With kernel 4.7.4-200.fc24.x86_64 this problem seems solved to me.

Comment 10 Guido Aulisi 2016-11-08 12:58:44 UTC
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-17 01:47:23 UTC
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-17 01:49:54 UTC
F24, btw.

Comment 13 Fedora End Of Life 2016-11-24 15:45:47 UTC
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 19:01:36 UTC
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.

Comment 15 krinkodot22 2018-05-05 22:03:01 UTC
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?


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