Bug 1550701 - Ethernet doesn't work after sleep
Summary: Ethernet doesn't work after sleep
Keywords:
Status: CLOSED DUPLICATE of bug 1580079
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 28
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-01 19:52 UTC by Alexander Zaitsev
Modified: 2018-11-25 22:46 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-21 08:41:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Alexander Zaitsev 2018-03-01 19:52:34 UTC
Description of problem:
Laptop with Fedora 27 cannot connect via Ethernet to a network after sleep (not hibernation).

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


How reproducible:
Always

Steps to Reproduce:
1. With connected or disconnected Ethernet cable (in my case doesn't matter) turn on sleep mode on a laptop.
2. Turn off sleep mode.
3. Ooops: Ethernet doesn't work. 

Actual results:
There is chance to get workable Ethernet connection after sleep.

Expected results:
Fedora should be able to establish Ethernet connection after sleep.

Additional info:
Laptop model: Asus K55VJ-SX012D
Fedora 27
KDE Plasma 5.11.5
KDE Frameworks 5.43.0
Qt: 5.9.4

lspci | grep Ethernet: 04:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a)

uname -r: 4.15.4-300.fc27.x86_64


On Windows 10 all works fine. Ethernet cable is fine (tested on Windows and on another machine).

Comment 1 Stephen Herr 2018-05-26 20:58:24 UTC
I also have this problem with Fedora 28. Let me know if you need any more troubleshooting information.

$ lspci | grep Ethernet
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

Comment 2 Stephen Herr 2018-05-27 04:54:50 UTC
A workaround seems to be to remove and reload the r8169 module after a sleep. This can be done automatically by creating a script for systemd to call:

$ sudo cat <<EOF > /usr/lib/systemd/system-sleep/fix_network
#!/bin/sh

case "$1" in
    pre)
        modprobe -r r8169
        ;;
    post)
        modprobe r8169
        ;;
esac
EOF

$ sudo chmod +x /usr/lib/systemd/system-sleep/fix_network

Thanks for the idea goes to Steven Rosenberg at:
http://stevenrosenberg.net/blog/linux/fedora/2015_0928_working_on_my_networking_after_suspend_resume_issue_in_fedora_22

Comment 3 Beniamino Galvani 2018-05-28 07:41:20 UTC
This looks similar to bug 1580079. Can you please show the output of 'ip l' and 'dmesg' after resume from sleep?

Comment 4 Beniamino Galvani 2018-06-21 08:41:40 UTC
Closing, please reopen if needed.

*** This bug has been marked as a duplicate of bug 1580079 ***

Comment 5 Alexander Zaitsev 2018-07-08 12:07:18 UTC
Since 4.17 kernel workaround from Stephen Herr doesn't work and I should restart compute for Ethernet enabling.

Comment 6 John Cooper 2018-07-12 15:01:45 UTC
I am seeing this for the first time at Fedora 28 in Kernel 4.17. Switch to 4.16 and the ethernet resumes from sleep as expected.

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

Can you please reopen this as the duplicate is old and has been closed anyway.

Comment 7 Licia Leanza 2018-11-25 14:20:10 UTC
I have the same problem on my:

Sony Vaio Vpcz21c5e
Fedora 29
4.19.2-301.fc29.x86_64
19:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

I have a workaround that is unplug and plug again the rj45 connector but it's really boring

Comment 8 Licia Leanza 2018-11-25 22:46:04 UTC
Followup to my previous note:

with kernel 4.18.18-300.fc29.x86_64 the problem doesn't occur.


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