 |
Note that booting the previous kernel works: 3.10.0-957.27.2.el7.x86_64 #1 SMP Mon Jul 29 17:46:05 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux The upgrade to the current 3.10.0-1062 is what breaks this. |
|
|
Same issue here on 3 of 4 workstations. The 4. workstation is waking up on WoL. [bsa.opag.ch:/root] ethtool enp7s0 Settings for enp7s0: Supported ports: [ TP AUI BNC MII FIBRE ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes [bsa.opag.ch:/root] lspci ... 07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) --- BIOS ACPI Sleep mode is set to S3. |
|
|
Looking at the 4. workstation (host montesa), where WoL is working: [root] ping montesa PING montesa (192.1.1.15) 56(84) bytes of data. ^C --- montesa ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1001ms [root] ether-wake montesa [root] ping montesa PING montesa (192.1.1.15) 56(84) bytes of data. From dhcp-118 (192.1.1.118) icmp_seq=1 Destination Host Unreachable ... From dhcp-118 (192.1.1.118) icmp_seq=36 Destination Host Unreachable 64 bytes from montesa (192.1.1.15): icmp_seq=37 ttl=64 time=2326 ms 64 bytes from montesa (192.1.1.15): icmp_seq=38 ttl=64 time=1326 ms --- [root@montesa:/root] ethtool enp7s0 Settings for enp7s0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000033 (51) drv probe ifdown ifup Link detected: yes -- [root@montesa:/root] lspci | grep Eth 07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) |
|
|
differences in output of ethtool: montesa: Supported ports: [ TP MII ] bsa: Supported ports: [ TP AUI BNC MII FIBRE ] --- [root@montesa:/root] cat /etc/sysconfig/network-scripts/ifcfg-enp7s0 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=enp7s0 UUID=b77ad498-6d0a-4f1a-994d-6da616931f12 DEVICE=enp7s0 ONBOOT=yes IPADDR=192.1.1.15 PREFIX=24 GATEWAY=192.1.1.1 DNS1=157.161.1.2 DNS2=157.161.255.133 DOMAIN=opag.ch [bsa.opag.ch:/root] cat /etc/sysconfig/network-scripts/ifcfg-enp7s0 HWADDR=50:E5:49:BE:F4:D8 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=enp7s0 UUID=61ce505f-620c-3972-b204-0869c0b1153f ONBOOT=yes AUTOCONNECT_PRIORITY=-999 IPADDR=192.168.1.40 PREFIX=24 GATEWAY=192.168.1.1 DNS1=192.168.1.1 DOMAIN=opag.ch ETHTOOL_OPTS="wol g" ZONE=public --- Note: montesa WoL is working, bsa WoL not working |
|
|
as mentioned in this article https://www.lisenet.com/2016/set-up-wake-on-lan-wol-on-centos-7/ Changing ifcfg-enp7s0 to ETHTOOL_OPTS="-s enp7s0 wol g" doesn't help. WoL still not working |
|
|
The following steps fixes WoL for me on host bsa: 1. remove ETHTOOL_OPTS in /etc/sysconfig/network-scripts/ifcfg-enp7s0 2. enable "Magic" via "Network Connections" gui (nm-connection-editor) See attached screenshot WoL01.png (49,276 bytes) |
|
|
withdrawing my last statement - three of our workstations still do not WoL |
|
|
Here's a CentOS forum entry which claims to be solved the issue: https://www.centos.org/forums/viewtopic.php?f=47&t=71861 |
|
|
Now this is weird: After re-checking our workstations, i noticed that the one station where WoL is working has "Wake-on: d" (see output of ethtool montesa above). I was curious trying it, and in fact WoL on bsa is WORKING now. With the Magic OFF! WoL02.png (52,136 bytes) |
|
|
Now i'm not sure about what ethtool reports and how to set wake-on-lan via nmcli correctly. man ethtool says: p Wake on PHY activity u Wake on unicast messages m Wake on multicast messages b Wake on broadcast messages a Wake on ARP g Wake on MagicPacket™ s Enable SecureOn™ password for MagicPacket™ d Disable (wake on nothing). This option clears all previous options. man nmcli -> man nm-settings (802-3 section) has more options than ethtool reports: wake-on-lan, uint32, 1 The NMSettingWiredWakeOnLan options to enable. Not all devices support all options. May be any combination of NM_SETTING_WIRED_WAKE_ON_LAN_PHY (0x2), NM_SETTING_WIRED_WAKE_ON_LAN_UNICAST (0x4), NM_SETTING_WIRED_WAKE_ON_LAN_MULTICAST (0x8), NM_SETTING_WIRED_WAKE_ON_LAN_BROADCAST(0x10), NM_SETTING_WIRED_WAKE_ON_LAN_ARP (0x20), NM_SETTING_WIRED_WAKE_ON_LAN_MAGIC (0x40) or the special values NM_SETTING_WIRED_WAKE_ON_LAN_DEFAULT (0x1) (to use global settings) and NM_SETTING_WIRED_WAKE_ON_LAN_IGNORE (0x8000) (to disable management of Wake-on-LAN inNetworkManager). Note that nmcli offers the option DEFAULT 0x1 besides IGNORE 0x8000, while ethtool only knows "Disable" |
|
|
As described in the forum post referenced above I was able to fix this for my desktop by running this command: nmcli c modify "enp3s0" 802-3-ethernet.auto-negotiate yes I assume with the new kernel the NIC's speed/duplex no longer matches the switch port's speed/duplex after the PC is suspended. My guess is that setting "802-3-ethernet.auto-negotiate yes" causes the NIC to keep the correct/matching speed/duplex auto negotiate setting after the computer is suspended. |
|
|
Forgot to share my hardware: $ lspci|grep Ethernet 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) |
|
|
I can confirm this bug. Happens with kernel-3.10.0-1062.12.1.el7.x86_64 as well. [root@server ~]# lspci|grep Ethernet 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09) |
|
|
The workaround with nmcli mentioned by jimj doesn't work for me. My card isn't managed by nm, and hasn't been in the past either. [root@server ~]# nmcli enp3s0: unmanaged "Realtek RTL8111/8168/8411" ethernet (r8169), 10:BF:48:86:A9:54, hw, mtu 1500 |
|
|
CentOS7 Kernel 3.10.0-862.6.3 --->3.10.0-1127.10.1 update NG. After updating the kernel in the same way as everyone, I can no longer boot with WOL. In ethtool, change to Wake-on :d ---> g, Changed wake-on-lan to "magic" in nmcli. But the situation didn't change. |
 |
I suggest attempting to replace the network driver provided by the distro with kmod-r8168-8.048.00-1.el7_7.elrepo.x86_64.rpm from ElRepo. If it works, file a bug at bugzilla.redhat.com and let them know about the issue. If it does not or if the module is incompatible with your kernel, file a RFE with ElRepo and kindly ask them to attempt to package r8168-8.048.03 |
|
|
Same situation here, confirmed works on kernel 957.1.3 and does not work on kernel 1127 with the Realtek NIC. Did someone try the ElRepo workaround suggested ? Any links to share ? |
|
|
Thank you @ManuelMolfshant - installing kmod-r8168 has fixed issue for me. Other suggestions from this thread didn't help. |
|
|
It's a very long shot given that EL7 is in maintenance mode and only important/security bug fixes are accepted by RedHat but if current kernel ( i.e. 3.10.0-1160.41.1.el7.x86_64 ) still fails, filing a bug in bugzilla.redhat.com and hoping for the best is the only way forward without resorting to ElRepo's kmod |
|
|
@Dark_Angel can you post a link and actions ? All I got didn't pass even the install phase |
 |
@scaprile Set up the elrepo repository by following: https://elrepo.org/tiki/HomePage and install the kmod package by: sudo yum install kmod-r8168 |
|
|
@toracat Oops, should've checked again... (I do have elrepo already setup). Last time I've checked I couldn't get the 8.048 version and whatever I got from the Internet was only headache prone stuff. Thanks a lot, sorry about missing the obvious. |
|
|
Marking this as 'resolved'. |
- Anonymous
