The easiest way to find something that could help is journalctl -r --boot=-1 after rebooting your laptop. These options will display all of the entries in reverse chronological order, starting from when you powered the computer off. When you find something complaining about waking from suspend, just look up that entry in a search engine. This method helped me many times, mostly with amdgpu bugs in the kernel fucking with my system.
Edit:
Absolutely nothing in journalctl, dmesg, etc 😭
Woops, didn’t read that. dmesg only keeps track of everything from the last boot, so unless you used SSH to remote into your laptop while it tried wake from suspend, you wouldn’t see anything anyways. journalctl on its own vomits out a metric fuckton of entries, but it does persist across reboots. If you use my aforementioned options or something like journalctl | grep suspend, it might be easier to find something
That’s the issue. The journal just… stops the moment it enters suspend. I now even have an alias for that specific purpose. No one seems to have this issue online.
Jul 0520:58:59 main systemd[1]: session-4.scope: Unit now frozen-by-parent.
Jul 0520:58:59 main systemd[1]: user-995.slice: Unit now frozen-by-parent.
Jul 0520:58:59 main systemd[1]: user.slice: Unit now frozen.
Jul 0520:58:59 main systemd[1]: user-1000.slice: Unit now frozen-by-parent.
Jul 0520:58:59 main systemd-sleep[82780]: Successfully froze unit 'user.slice'.
Jul 0520:58:59 main systemd-sleep[82780]: Performing sleep operation 'suspend'...
Jul 0520:58:59 main kernel: PM: suspend entry (deep)
(END)
I appreciate your help though. Someday, I’ll get it fixed.
Based on the information given in logs + the rest of the thread thus far, I’d assume the problem either lies in a kernel bug or the laptops’ firmware, BIOS. The logs claim the system successfully going into S3 (deep) sleep. It’s possible for the affected laptops to have broken S3 suspend behavior.
A few things that might be worth checking include seeing if other sleep modes (s2idle) are available and testing them, checking for BIOS updates, and checking for Linux/generic suspend options within the BIOS.
Some modern laptops have completely removed support for S3 sleep, as well as some still include it but clearly never tested it. I have seen multiple OEMs that have S3 sleep “available” but with the Windows installation utilizing S0 by default. If such OEMs are lazy (which a lot of them are), they just won’t bother to properly test the functionality as long as the default OS configuration they ship works. Same kind of deal now with how many OEMs (mostly used to) ship non-standard ACPI implementations that required extra drivers in Windows to function (or would just not work correctly under Linux).
The other commenter gave useful information, but I would implore that you try to change your suspend mode from “deep” to “s2idle”. Deep (S3) sleep, alongside S4 sleep, are unfortunately not very well supported by manufacturers, at least from what I’ve heard.
The easiest way to find something that could help is
journalctl -r --boot=-1after rebooting your laptop. These options will display all of the entries in reverse chronological order, starting from when you powered the computer off. When you find something complaining about waking from suspend, just look up that entry in a search engine. This method helped me many times, mostly with amdgpu bugs in the kernel fucking with my system.Edit:
Woops, didn’t read that.
dmesgonly keeps track of everything from the last boot, so unless you used SSH to remote into your laptop while it tried wake from suspend, you wouldn’t see anything anyways.journalctlon its own vomits out a metric fuckton of entries, but it does persist across reboots. If you use my aforementioned options or something likejournalctl | grep suspend, it might be easier to find somethingThat’s the issue. The journal just… stops the moment it enters suspend. I now even have an alias for that specific purpose. No one seems to have this issue online.
Jul 05 20:58:59 main systemd[1]: session-4.scope: Unit now frozen-by-parent. Jul 05 20:58:59 main systemd[1]: user-995.slice: Unit now frozen-by-parent. Jul 05 20:58:59 main systemd[1]: user.slice: Unit now frozen. Jul 05 20:58:59 main systemd[1]: user-1000.slice: Unit now frozen-by-parent. Jul 05 20:58:59 main systemd-sleep[82780]: Successfully froze unit 'user.slice'. Jul 05 20:58:59 main systemd-sleep[82780]: Performing sleep operation 'suspend'... Jul 05 20:58:59 main kernel: PM: suspend entry (deep) (END)I appreciate your help though. Someday, I’ll get it fixed.
Based on the information given in logs + the rest of the thread thus far, I’d assume the problem either lies in a kernel bug or the laptops’ firmware, BIOS. The logs claim the system successfully going into S3 (deep) sleep. It’s possible for the affected laptops to have broken S3 suspend behavior.
A few things that might be worth checking include seeing if other sleep modes (s2idle) are available and testing them, checking for BIOS updates, and checking for Linux/generic suspend options within the BIOS.
Just did it and s2idle works! Thank you.
Didn’t a lot of laptops completely remove S3 sleep in favor of S0 sleep
Some modern laptops have completely removed support for S3 sleep, as well as some still include it but clearly never tested it. I have seen multiple OEMs that have S3 sleep “available” but with the Windows installation utilizing S0 by default. If such OEMs are lazy (which a lot of them are), they just won’t bother to properly test the functionality as long as the default OS configuration they ship works. Same kind of deal now with how many OEMs (mostly used to) ship non-standard ACPI implementations that required extra drivers in Windows to function (or would just not work correctly under Linux).
The other commenter gave useful information, but I would implore that you try to change your suspend mode from “deep” to “s2idle”. Deep (S3) sleep, alongside S4 sleep, are unfortunately not very well supported by manufacturers, at least from what I’ve heard.