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.
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.
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.