[solved] PC turns itself on after sleep + wake on lan + shutdown

Strangiato · 2021-12-08 11:02:30

Hi

My computer turns itself on 5 seconds after suspend to RAM + wake on lan (using an Android phone) +
shutdown.

My motherboard is Gigabyte GA-B85M-D3PH, it has this ethernet adapter:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
        Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet
        Flags: bus master, fast devsel, latency 0, IRQ 18
        I/O ports at e000 [size=256]
        Memory at f7c00000 (64-bit, non-prefetchable) [size=4K]
        Memory at f0000000 (64-bit, prefetchable) [size=16K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
        Capabilities: [d0] Vital Product Data
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
        Kernel driver in use: r8169
        Kernel modules: r8169, r8168

The problem occurs regardless the driver used is r8168 or r8169.

I have added xhci_hcd.quirks=270336 kernel boot parameter to my GRUB, and disabled all references to xHCI
and enabled wake up on keyboard actions in BIOS setup according to Arch wiki.

https://wiki.archlinux.org/title/Wake-o … r_shutdown

My motherboard does not have EuP 2013 setting. I have disabled Erp instead but the problem persists.

Tested these kernels:
linux-lts 5.10.83
linux 5.15.6
linux-zen 5.15.6

Is there any solution/workaround to this problem?
Thanks.

Last edited by Strangiato (2022-10-14 12:41:10)

Strangiato · 2021-12-14 20:32:52

I'm still searching for a solution/workaround.

My PC also wakes up spontaneously after suspend to RAM + wake on lan + suspend to RAM.

Strike0 · 2021-12-14 21:08:49

What setting does it show for WOL?

Output here is:

# ethtool enp1s0
....
        Supports Wake-on: pumbg
	Wake-on: d
	Link detected: yes

where d means disabled (I did not disable it actively, the wiki has the info to do so).

How does your machine connect (which tool, dhcp or static IP)?

Strangiato · 2021-12-14 21:19:18

I use network manager with static IP.
Output on my system:

$ sudo ethtool enp4s0
Settings for enp4s0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Half 1000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	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: Symmetric Receive-only
	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
	Auto-negotiation: on
	master-slave cfg: preferred slave
	master-slave status: slave
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: external
	MDI-X: Unknown
	Supports Wake-on: pumbg
	Wake-on: g
	Link detected: yes

Strike0 · 2021-12-15 10:08:43

Ok. Now what is not clear to me from your post so far:
Do you actually need WOL to reach the machine sometimes, but the spurious wakeups are the problem?
Or don't you need it and it can be disabled altogether?

If you don't need it, the straight-forward thing would be to set the wake-on parameter to "d". For that I would stop the networkmanager service (important), issue a

# ethtool -s net0 wol d

and shutdown. After the next boot the interface should still show "d", after NM brought the connection up.

If you need WOL occasionally to reach the machine, I don't have much more hints than those you have tried from the wiki already. One method to work-around may be to configure WOL only for suspend-to-ram, but disable it for shutdown. Another try may be to see if one can change the WOL magic packet ("g") parameter.

Do you need WOL or not?

Strangiato · 2021-12-15 10:18:15

I need WOL to reach the machine sometimes, the spurious wakeups are the problem.

Could this be an ethernet driver bug? If so, where to report bug in Realtek ethernet driver?

Thanks for your help.

Strike0 · 2021-12-15 10:59:02

Could be, but it is one of the most common ethernet chips. Also, from what I have read these spurious wakeup problems are often bugs in the motherboard BIOS.[1] You should first check, if there is another update for the board. For this BIOS reason I am unsure, if another workaround could be to buy a basic extra network adapter card (not usb, but internal pci/isa slot with another vendor) to use for WOL exclusively. Perhaps research that option for your board too.

[1] https://www.phoronix.com/scan.php?page= … oL-Control

Strangiato · 2021-12-15 11:41:44

There is a bios update to my motherboard, but this is the only change:

Update CPU microcode for win10 support with Pentium AE

I have Windows 7 installed on the same computer, but currently I'm unable to test wake on lan on it because suspend to RAM feature is not working (screen is locked when I try to suspend). I will open a bug report against the ethernet driver. If nothing to change, possibly I will buy a pci ethernet adapter as you have suggested. Thanks for your help again.

Strike0 · 2021-12-16 07:46:15

A first test may be to change the WOL parameters of the Linux driver (using ethertool). Then, independent from WOL you should definetely troubleshoot suspend-to-ram first, and after that hibernate-to-disk. Both rely on correct functioning of more basic ACPI sleep states of the motherboard than a poweroff. Perhaps you find that hibernate works, and then the WOL with it. For example, I have a motherboard (Asus) where suspend/hibernate worked fine, but hibernate failed once the CPU was upgraded to a later model. If either fails on your board too, it is very unlikely WOL will start to work (with any ethernet adapter).
The WOL-responsible ethernet driver in your case (spurious wakeup from poweroff) is the module in the BIOS, i.e. not the Linux module but how Gigabyte integrated the Realtek supplied driver module into the BIOS. To troubleshoot that WOL your mileage is probably best in a Gigabyte-user forum. Likewise you may find info there on whether a user got working WOL with an extra ethernet card.

seth · 2021-12-16 09:34:48

Did you wireshark the NIC to ensure that there's not something on the segment constantly sending magic packages around?

Because

My PC also wakes up spontaneously after suspend to RAM + wake on lan + suspend to RAM.

Can you please elaborate on this? You S3 fine, then send a WOL package from your phone, the system wakes as expected, then you S3 again but *this* time it immediately resumes?
If you disable the WOL after the desired WOL after the 1st S3, can you then successfully S3 ?

Do you have other devices (that are all not smartphones) to WOL the system instead?

Strangiato · 2021-12-16 12:19:28

seth wrote:

Did you wireshark the NIC to ensure that there's not something on the segment constantly sending magic packages around?

I do not think that is the problem. I have followed these steps:
1. suspend to RAM
2. wake on lan
3. disconnected network cable from the ethernet adapter
4. suspend to RAM
Result: PC woke up sponteneously after 5 seconds.

Because
My PC also wakes up spontaneously after suspend to RAM + wake on lan + suspend to RAM.
Can you please elaborate on this? You S3 fine, then send a WOL package from your phone, the system wakes as expected, then you S3 again but *this* time it immediately resumes?

Exactly.

If you disable the WOL after the desired WOL after the 1st S3, can you then successfully S3 ?

Followed these steps:
1. suspend to RAM
2. wake on lan
3. disabled wol by running 'sudo ethtool -s enp4s0 wol d'
4. suspend to RAM
Result: sponteneous wake up occured after 5 seconds again

Do you have other devices (that are all not smartphones) to WOL the system instead?

Tested with my laptop running Arch + Gnome + gWakeOnLan and got sponteneous wake up too.

I have fixed suspend to RAM on my Windows 7 by disabling hybrid suspend, despite I got a BSOD after the first suspend/wakeup cycle done immediately after disabling hybrid suspend lol. I have followed these steps ~10 times:
1. suspend to RAM
2. wake on lan with my Android 6 phone
3. suspend to RAM

I got sponteneous wake up just once.

Also I did this test just once:
1. suspend to RAM
2. wake on lan with my Android 6 phone
3. shutdown

And my PC did not turn itself on.

Apparently my motherboard is not the problem.

Last edited by Strangiato (2021-12-16 12:21:24)

seth · 2021-12-16 13:42:22

Strangiato wrote:

I have fixed suspend to RAM on my Windows 7 by disabling hybrid suspend, despite I got a BSOD after the first suspend/wakeup cycle done immediately after disabling hybrid suspend lol. I have followed these steps ~10 times:

While windows 7 idn't have that "fast-start" feature (which is just hibernation…) make sure that windows isn't hibernating while running arch. Ie. properly shut down windows before booting into any other OS.

Strangiato · 2021-12-16 14:20:05

Followed these steps:
1. booted Windows 7
2. turned PC off
3. booted Arch

Sponteneous wake up is still reproducible.

Strike0 wrote:

A first test may be to change the WOL parameters of the Linux driver (using ethertool). Then, independent from WOL you should definetely troubleshoot suspend-to-ram first, and after that hibernate-to-disk. Both rely on correct functioning of more basic ACPI sleep states of the motherboard than a poweroff. Perhaps you find that hibernate works, and then the WOL with it. For example, I have a motherboard (Asus) where suspend/hibernate worked fine, but hibernate failed once the CPU was upgraded to a later model. If either fails on your board too, it is very unlikely WOL will start to work (with any ethernet adapter).
The WOL-responsible ethernet driver in your case (spurious wakeup from poweroff) is the module in the BIOS, i.e. not the Linux module but how Gigabyte integrated the Realtek supplied driver module into the BIOS. To troubleshoot that WOL your mileage is probably best in a Gigabyte-user forum. Likewise you may find info there on whether a user got working WOL with an extra ethernet card.

Hibernation is disabled on my Arch. Suspend to RAM without wake on lan before always works as expected.

Last edited by Strangiato (2021-12-16 14:20:52)

seth · 2021-12-16 14:54:53

Is this strictly related to the WOL situation or do you get spurious wakeups after the 2nd S3 regardless of what triggered the 1st or whether WOL is ever enabled at all?

Strangiato · 2021-12-16 15:06:06

I had never seen spurious wakeup after S3 before enabling wake on lan recently. My Arch is old, it was installed on february 2018.

Strike0 · 2021-12-17 08:26:30

Strangiato wrote:

Apparently my motherboard is not the problem.

Well, you changed ACPI settings in the BIOS to enable WOL in the first place (which may trigger the bug). And in the post you refer to one spontaneous wake-up with W7 too.
The reason I was referring to hibernate (which you disabled on arch), was simply to suggest it as an alternative power-save mode while the machine waits for WOL. But it makes no real sense to try that as long as the spurious wakeups during suspend/S3 are so common.

Strangiato wrote:

...Followed these steps:
1. suspend to RAM
2. wake on lan
3. disabled wol by running 'sudo ethtool -s enp4s0 wol d'
4. suspend to RAM
Result: sponteneous wake up occured after 5 seconds again

This does not rule out a bug has been triggered in the BIOS either.
Yet, apart from a BIOS or Linux bug there may be other reasons in this test. First, if you do your tests quickly, the router may still work of some sort of connection/arp cache (trying to ping the already suspended machine). Second, your active WOL configuration in networkmanager (NM) may reset your step 3. before the suspend.

Please try this test again, but first stop/disable NM as new step 2.5. I bet a vegan taco you won't see a spurious wakeup. Then wake the machine up and check the WOL setting of the driver. If it stays on disable, try that again with started/enabled NM and also check the WOL setting.

Strangiato · 2021-12-17 11:38:58

Strike0 wrote:

Strangiato wrote:
Apparently my motherboard is not the problem.
Well, you changed ACPI settings in the BIOS to enable WOL in the first place (which may trigger the bug). And in the post you refer to one spontaneous wake-up with W7 too.
The reason I was referring to hibernate (which you disabled on arch), was simply to suggest it as an alternative power-save mode while the machine waits for WOL. But it makes no real sense to try that as long as the spurious wakeups during suspend/S3 are so common.
Strangiato wrote:
...Followed these steps:
1. suspend to RAM
2. wake on lan
3. disabled wol by running 'sudo ethtool -s enp4s0 wol d'
4. suspend to RAM
Result: sponteneous wake up occured after 5 seconds again
This does not rule out a bug has been triggered in the BIOS either.
Yet, apart from a BIOS or Linux bug there may be other reasons in this test. First, if you do your tests quickly, the router may still work of some sort of connection/arp cache (trying to ping the already suspended machine). Second, your active WOL configuration in networkmanager (NM) may reset your step 3. before the suspend.
Please try this test again, but first stop/disable NM as new step 2.5. I bet a vegan taco you won't see a spurious wakeup. Then wake the machine up and check the WOL setting of the driver. If it stays on disable, try that again with started/enabled NM and also check the WOL setting.

Followed these steps:
1. suspend to RAM
2. wake on lan
3. disabled network manager service by running 'sudo systemctl stop NetworkManager'
4. disabled wol by running 'sudo ethtool -s enp4s0 wol d'
5. suspend to RAM

Spurious wakeup occured again.

Wake on lan is enabled by default in my motherboard. In my previous comment I said:

I had never seen spurious wakeup after S3 before enabling wake on lan recently.

But this claim is not accurate. The accurate one is:

I had never seen spurious wakeup after S3 before starting to use wake on lan recently.

When I started to use wol recently, my system was running r8168 driver because I had the following problem with r8169 in the past:
https://bbs.archlinux.org/viewtopic.php?pid=1913620

Wake on lan is enabled by default in r8168 driver too (at least I don't remember enabling it manually in the past).

After I noticed that wol was not working well with r8168 driver (it gave me spurious wakeup too and wol was not working after shutdown),
I removed r8169 driver from the blacklist and I'm using it since then.

seth · 2021-12-17 15:22:01

Let's try to establish a baseline
* If you disable WOL (in the driver) can you repeatedly S3 and wake (w/ the keyboard) w/o similar symptoms?
* If you enable WOL, S3, wake, unload the r1868/9 module, S3 again: do you still get spurious wake-ups?

And see whether we can fool the ACPI table:
* If you enable WOL, S3, wake, S3/wake w/ rtcwake, S3 again: do you still get spurious wake-ups?

Last edited by seth (2021-12-17 15:22:12)

Strangiato · 2021-12-17 16:02:12

seth wrote:

Let's try to establish a baseline
* If you disable WOL (in the driver) can you repeatedly S3 and wake (w/ the keyboard) w/o similar symptoms?

Spurious wakeup never occurs after suspend to RAM + wake with keyboard + suspend to RAM even when wol is enabled.

* If you enable WOL, S3, wake, unload the r1868/9 module, S3 again: do you still get spurious wake-ups?

yes

And see whether we can fool the ACPI table:
* If you enable WOL, S3, wake, S3/wake w/ rtcwake, S3 again: do you still get spurious wake-ups?

Followed these steps:
1. suspend to RAM
2. wake on lan
3. S3/wake by running 'sudo rtcwake -m mem -s 10' (wakeup occured almost immediately after this command instead of after 10 seconds)
4. suspend to RAM

Spurious wakeup did NOT occur after the step 4.

Last edited by Strangiato (2021-12-17 16:03:19)

Strike0 · 2021-12-17 16:28:00

Strangiato wrote:

seth wrote:
Let's try to establish a baseline
* If you disable WOL (in the driver) can you repeatedly S3 and wake (w/ the keyboard) w/o similar symptoms?
Spurious wakeup never occurs after suspend to RAM + wake with keyboard + suspend to RAM even when wol is enabled.

And if you disable WOL like Seth suggested, does the driver change state back to "g" automatically after wakeup, or stay on "d"?

Strangiato · 2021-12-17 16:41:43

Strike0 wrote:

Strangiato wrote:
seth wrote:
Let's try to establish a baseline
* If you disable WOL (in the driver) can you repeatedly S3 and wake (w/ the keyboard) w/o similar symptoms?
Spurious wakeup never occurs after suspend to RAM + wake with keyboard + suspend to RAM even when wol is enabled.
And if you disable WOL like Seth suggested, does the driver change state back to "g" automatically after wakeup, or stay on "d"?

It stays on 'd'.

seth · 2021-12-17 21:49:31

Spurious wakeup did NOT occur after the step 4.

Does the system keep waking up from subsequent S3 when NOT attempting an RTC wake or does any S3 after the WOL clear the stage?
(ie. s3, wol, s3, wake by error, s3 => ?)

Strangiato · 2021-12-17 22:04:51

seth wrote:

Spurious wakeup did NOT occur after the step 4.
Does the system keep waking up from subsequent S3 when NOT attempting an RTC wake or does any S3 after the WOL clear the stage?
(ie. s3, wol, s3, wake by error, s3 => ?)

spurious wake-up does NOT occur after your steps.

Strike0 · 2021-12-18 08:53:16

This last result sounds encouraging. I wonder if it is consistent, or a fluke.

The result made me skim through the kernel and arch bug trackers a little, the following current one reads related to your spurious wakeups:
https://bugzilla.kernel.org/show_bug.cgi?id=208033

Have a try if spurious wakeups return, if you ensure to s3/wake one time manually like the bug-reporter before leaving the machine (with WOL active).

Strangiato · 2021-12-18 12:07:37

Strike0 wrote:

This last result sounds encouraging. I wonder if it is consistent, or a fluke.
The result made me skim through the kernel and arch bug trackers a little, the following current one reads related to your spurious wakeups:
https://bugzilla.kernel.org/show_bug.cgi?id=208033
Have a try if spurious wakeups return, if you ensure to s3/wake one time manually like the bug-reporter before leaving the machine (with WOL active).

I think that my problem is different.
Followed these steps:
1. configured auto-suspend timeout to 1 minute
2. waited for auto-suspend timeout (PC suspended to RAM as expected)
3. wake on lan with Android 6 phone
4. waited for auto-suspend timeout again

Result: PC auto-suspended again then spurious wake-up happened immediately

Arch Linux

#1 2021-12-08 11:02:30

[solved] PC turns itself on after sleep + wake on lan + shutdown

#2 2021-12-14 20:32:52

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#3 2021-12-14 21:08:49

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#4 2021-12-14 21:19:18

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#5 2021-12-15 10:08:43

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#6 2021-12-15 10:18:15

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#7 2021-12-15 10:59:02

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#8 2021-12-15 11:41:44

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#9 2021-12-16 07:46:15

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#10 2021-12-16 09:34:48

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#11 2021-12-16 12:19:28

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#12 2021-12-16 13:42:22

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#13 2021-12-16 14:20:05

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#14 2021-12-16 14:54:53

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#15 2021-12-16 15:06:06

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#16 2021-12-17 08:26:30

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#17 2021-12-17 11:38:58

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#18 2021-12-17 15:22:01

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#19 2021-12-17 16:02:12

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#20 2021-12-17 16:28:00

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#21 2021-12-17 16:41:43

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#22 2021-12-17 21:49:31

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#23 2021-12-17 22:04:51

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#24 2021-12-18 08:53:16

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

#25 2021-12-18 12:07:37

Re: [solved] PC turns itself on after sleep + wake on lan + shutdown

Board footer