Bug 208033
| Summary: | r8169 wake-on-lan (WOL) works only after a manual suspend/resume cycle | ||
|---|---|---|---|
| Product: | Networking | Reporter: | jackdroido |
| Component: | Other | Assignee: | Stephen Hemminger (stephen) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | hkallweit1 |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 5.6.15 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
before setting WoL
after setting WoL and before first suspend after resume from first suspend |
||
|
Description
jackdroido
2020-06-02 19:12:51 UTC
The following looks a little bit suspicious. What is your link partner? Is it 1Gbps capable? Is it configured for autonegotiation? Link partner advertised link modes: Not reported Link partner advertised pause frame use: No Link partner advertised auto-negotiation: No Link partner advertised FEC modes: No Speed: 100Mb/s Duplex: Full Auto-negotiation: on Did WoL work properly on an earlier kernel version? The PCI status details show that PME is disabled. This should not be the case after enabling WoL. Do you have an active link whilst enabling WoL? Or do you enable WoL with no link and establish the link later? Thanks for replying. PC is connected directly to a 10/100 TP-Link router (hence the speed) the only one I have at hand sadly. First time I tested WoL was around end-2019, so I would say with a 5.4.x kernel. Same result. WoL is activated at boot via NetworkManager, but also tried excluding it and just do: # ip link set up # ethtool -s enp2s0 wol g Same result too. The link LED on the router is on even during the first suspend (where WoL is not functional). A little context: I ran the commands above just after poweron, before any suspend test. I can run them again after resuming if it helps... I'd be interested in the following: - lspci -vv output for the network card (grepped for PME) - ethtool -d <if> output in these three situations (with WoL setting by NetworkManager disabled): 1. before setting WoL 2. after setting WoL and before first suspend 3. after resume from first suspend Created attachment 289485 [details]
before setting WoL
Created attachment 289487 [details]
after setting WoL and before first suspend
Created attachment 289489 [details]
after resume from first suspend
Thanks for testing. All that looks normal. Also I can't reproduce the issue here with RTL8168g. What you can check in addition: After first unsuccessful WoL, please do a "grep PME /proc/interrupts". Each WoL event should generate a PME interrupt. Indeed, PME interrupts are there: $ grep PME /proc/interrupts 122: 0 0 0 0 IR-PCI-MSI 311296-edge PCIe PME 123: 2 0 0 0 IR-PCI-MSI 315392-edge PCIe PME (one for the first wakeup via keyboard, one for the second via magic packet) To rule out problems with the router, I tried connecting the PC directly in cross with my laptop. Same result. If also the first (failed) attempt generated a PME interrupt, then the network chip did all it can do. So maybe the issue is system-specific, IOW it may be a BIOS bug. A hint that root cause isn't in network driver is also that you face the same issue with the vendor driver. Thanks for looking at it. I don't follow you here: "...the first (failed) attempt generated a PME interrupt...", when there is only one PME related to the (successful) WoL (the other comes from the keyboard). Forgive me in advance, if I misunderstand you. PME's are triggered by PCI devices, therefore a keystroke doesn't generate a PME. My understanding is that at the first suspend you send a WoL packet, and because this doesn't work press a key afterwards. I interpret the two PME's in a way that the first WoL packet generates a PME, but a lower level doesn't translate the PME into a system wakeup. Thanks for clarifying. One thing I forgot to mention (but I think is not relevant at this point) is I also tried playing (with no success) with pcie_aspm parameter as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1671958 (and related issues). Got any other advice or things to try (maybe outside the network layer), before I start to dismantle the damn thing ? (just kidding :-) The referenced ASPM issue has been solved for quite some time. Well, we now know that the first WoL attempt generates a PME. You could check whether this PME interrupt generates an ACPI interrupt. For this check whether /sys/firmware/acpi/interrupts/gpe_all gets incremented. This info doesn't help me as I'm just a simple network driver maintainer. But maybe it helps some other guy looking at the issue who's more fit with the ACPI subsystem. Last but not least you could play a little with all wake-related BIOS settings. For example I can remember one quite old Gigabyte BIOS issue that could be resolved by enabling "LAN Boot ROM" in the BIOS. OK, here's the info:
1. first suspend, sent magic packet, then wakeup by keyboard:
+ grep PME /proc/interrupts
122: 0 0 0 0 IR-PCI-MSI 311296-edge PCIe PME
123: 1 0 0 0 IR-PCI-MSI 315392-edge PCIe PME
+ cat /sys/firmware/acpi/interrupts/gpe_all
2
2. second suspend, wakeup by magic packet:
+ grep PME /proc/interrupts
122: 0 0 0 0 IR-PCI-MSI 311296-edge PCIe PME
123: 2 0 0 0 IR-PCI-MSI 315392-edge PCIe PME
+ cat /sys/firmware/acpi/interrupts/gpe_all
2
3. third suspend, wakeup by keyboard:
+ grep PME /proc/interrupts
122: 0 0 0 0 IR-PCI-MSI 311296-edge PCIe PME
123: 2 0 0 0 IR-PCI-MSI 315392-edge PCIe PME
+ cat /sys/firmware/acpi/interrupts/gpe_all
4
So it seems gpe is incremented only for keyboard wakeup.
On the BIOS front, I thikk I tried toggling every possible entry (including Enable EFI LAN driver, CSM Option ROM, S5 USB Wakeup Support...) without success.
There is even a FAQ entry for the thing on the vendor site: https://www.gigabyte.com/Support/FAQ/2676.
The mentioned setting was already Disabled by default.
So I tried to set it to Enabled (despite the description explicitly sayin that doing so will DISABLE WoL functionality)... and guess what ? No change at all, same behaviour !
Feel free to reassign the bug or adding "some other guy" to CC list. And again, thank you for your attention.
|