> Through some digging, I found that when a desktop enters S3 sleep, the system cuts power to PCIe GPUs
I am not sure how correct this assumption is. S3 is supposed to cut power to everything but RAM, but for example Gigabyte Aorus motherboards are notorious for an NVMe SSD sleep bug that randomly prevents the system from properly sleeping or waking.
This is fixed by adding the following udev rule:
# Generic PCIe fix for sleep bugs by preventing wakeup from any PCIe port
ACTION=="offline", SUBSYSTEM=="pci", DRIVER=="pcieport", ATTR{power/wakeup}="disabled"
or more targeted:
# Gigabyte sleep fix by preventing wakeup from problematic PCIe port, depends on motherboard model
ACTION=="offline", SUBSYSTEM=="pci", ATTR{vendor}=="0x8086", ATTR{device}=="0x43bc", ATTR{power/wakeup}="disabled"
You can find any glitched PCIe wakeup device with:
1. cat /proc/acpi/wakeup (you'll have to trial and error your way through the wakeup devices if it isn't immediately clear)
2. cat /sys/class/pci_bus/*/*/yourWakeupDevicePci/uevent | grep PCI_ID
3. prepend "0x"
You also have the option of:
udevadm info --attribute-walk /dev/whatever
but for that you need to know some basic identifier of your glitchy device.
Or if you want to shellscript it (less reliable than letting udev do it for you and needs to be done via systemd service file or another automation):
# Gigabyte sleep fix, port depends on mobo model
/bin/bash -c 'if grep 'RP05' /proc/acpi/wakeup | grep -q 'enabled'; then echo 'RP05' > /proc/acpi/wakeup; fi'";
Yes I really hate this (and other) Linux sleep issues.
And my Logitech Bolt receiver wakes multiple of my Linux computers instantly, I don't know why it doesn't do that on Windows and haven't tried doing a USB capture (and don't know what equipment I'd need to try it out, logic analyzer? Glasgow?). In the meantime I've added a rule to block that:
KERNELS=="0000:00:01.1" sounds like an interesting way to do it, since you can target separate functions of the PCI device (in this case: domain 0, bus 0, slot 1, function 1).
As somebody with an Aorus motherboard who has probably burned a few kWh on this issue, I was really excited to try these solutions - no luck. Thank you anyway!
Did you try the general fix? And reload udev rules?
You also have to make sure it applies after the default rules.
You can check if the rule applies once you have everything set up by doing an `udevadm` attribute walk of your SSD device (not partition), and then following it up all the way up the device tree until you see your specific device port (target fix) or PCIe driver subsystem (general fix). Then check if "power/wakeup" is set to "disabled". If it is set to disabled, something else is keeping your device awake on sleep.
For that you can check /proc/acpi/wakeup, and there's also a specific systemd invocation (that I forgot) you can do that shows if your device slept, how long it slept, how much battery was drained, and if your device woke-up, slept or failed to resume, it'll give you a reason.. to the best of its ability.
Yes, my problem was with an Aorus ATX motherboard too.
> The system seems to go into sleep state just fine, it just freezes when waking up again
The behavior differs per device. Some sleep but freeze on wakeup, some immediately wakeup after sleeping, and some (like mine) will go to sleep 98% of the way, but the fans keep spinning. That was a dead giveaway for me that the bug was triggered. I suspect that on some systems, either the fans turn off and the system succeeded to getting to sleep 99% of the way, or the fans are so quiet that people do not notice them. And from that limbo state you can only recover with a hardware shutdown or interrupting power.
I'm fairly certain this issue is fixable for you as well, either with only this fix (and we just have to find the proper port(s), or with this fix and for whatever other device might be causing this issue.
Yiikes, on my B550M DS3H, previously when I woke my PC from sleep immediately after it slept (eg. by pressing the keyboard or case power button), it would "wake" after 0.5 seconds asleep and turn on the power light but not respond to user input, and not even shut down if I held the power button for 4 seconds! I had to pull power at the wall. This behavior occurred on both Windows and Linux, and was fixed at some point in a BIOS update.
Wow, thanks for this tip! I've been dealing with suspend issues with an X570 Aorus Master as well.
Running `echo GPP0 >> /proc/acpi/wakeup` into a systemd unit at boot solved the issue for me... except the first sleep after a boot would always wake back up immediately.
I applied your udev rule and that issue seems to be resolved as well!
I just did `ExecStart` with `multi-user.target`. That implies the unit is `simple`, so it very well could be sequencing incorrectly at boot and failing. That's a good point; I'll have to keep that in mind!
Apologies for the confusion, I don't mean it was failing to run.
If you don't add "RemainAfterExit", the service will run at every boot, because after a reboot it is considered "inactive. This will execute your shell code, which effectively toggles wakeup.
"RemainAfterExit" is meant for unit files that change the state of your system. After running once, the service will be considered "active", until you manually deactivate it, which will execute whatever you might have set in "ExecStop".
"Type=Oneshot" is necessary for "RemainAfterExit".
In this case I still would prefer doing it via udev though. I've made it my rule of thumb to evade shell scripting wherever feasible, because it usually ends up being more brittle, and more prone to footgunning :)
> I am not sure how correct this assumption is. S3 is supposed to cut power to everything but RAM, but for example Gigabyte Aorus motherboards are notorious for an NVMe SSD sleep bug that randomly prevents the system from properly sleeping or waking.
You would hope that you could probe the hardware to see if it really is in sleep or not, or that re-waking the hardware would not cause issue if it never went to sleep.
Also I would expect that you could send a sleep command to the PCIe device, then try to sleep the bus itself. The to wake you would bring back the bus and then wake the device.
Any further insight you might have on these Aorus wakeup issues? In particular, it seems the wakeup in my case is coming from `.../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:45/wakeup/wakeup6` which does not really mean anything to me.
I had this issue and this MB for years I eventually solved it by physically removing a crappy USB C PCIE card I'd bought because my case didn't have any USBC ports.
(Additionally I also previously disabled PCI wakeup buses and haven't touched it again since it's working)
I am not sure how correct this assumption is. S3 is supposed to cut power to everything but RAM, but for example Gigabyte Aorus motherboards are notorious for an NVMe SSD sleep bug that randomly prevents the system from properly sleeping or waking.
This is fixed by adding the following udev rule:
or more targeted: You can find any glitched PCIe wakeup device with: You also have the option of: but for that you need to know some basic identifier of your glitchy device.Or if you want to shellscript it (less reliable than letting udev do it for you and needs to be done via systemd service file or another automation):
Yes I really hate this (and other) Linux sleep issues.