Laptop occasionaly fails to wake from sleep

[AWalrus]

When suspending the laptop to s2idle either through Gnome menus, the power button, or systemctl suspend the laptop will sometimes go to sleep properly, and sometimes it will go into an unresponsive state where the screen is black, the led around the power button stays on and the fans keep spinning. The only way to leave this state is to hold power button for complete shutdown and boot again.

Looking through the logs it fails to suspend correctly 1 out of 3 times approximately.

This doesn’t happen on Fedora, so I don’t think it’s a hardware problem, rather an issue with some config.

General Details:

• System76 Pangolin
• AMD Ryzen™ 7 6800U with Radeon™ Graphics × 16
• Linux 6.7.2-arch1-1
• Firmware version: ARB928_V00.01_T0025ASY1_ms (this is the newest version)

Installed EndeavorOS a few days ago and didn’t change much config.

Journalctl:

When it fails the journal looks something like this, where the next boot is after I had to hold the power button to get out of the “zombie” state.

Jan 28 22:32:52 pangolin systemd[1]: Reached target Sleep.
Jan 28 22:32:52 pangolin systemd[1]: Starting System Suspend...
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Successfully made thread 1408 of process 1374 owned by '1000' high priority at nice level 0.
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Supervising 7 threads of 4 processes of 1 users.
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Supervising 6 threads of 3 processes of 1 users.
Jan 28 22:32:52 pangolin systemd-sleep[6483]: Performing sleep operation 'suspend'...
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Supervising 6 threads of 3 processes of 1 users.
Jan 28 22:32:52 pangolin kernel: PM: suspend entry (s2idle)
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Successfully made thread 1408 of process 1374 owned by '1000' RT at priority 20.
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Supervising 7 threads of 4 processes of 1 users.
-- Boot 423200e78544499aa6d14fd2df3e10f9 --

Any help appreciated, thanks!

[anthony93]

First of all, set up the SysReq key first so that you don’t have to force shut down with the power button when your system craps itself.

[Tip] Enable Magic SysRq Key (REISUB)

The Linux kernel authors have provided a very nice feature of issuing low-level commands to the kernel directly, regardless of the state the system is in. This is called the “Magic SysRq Key”, because these commands are issued by pressing the SysRq key on the keyboard (if you can’t find it, typically, it shares the same physical key as the Print Screen key, but on some laptops it can be elsewhere). A common use is to reboot when the computer freezes and becomes unresponsive due to some software…

In the meantime, here are a couple of things you can try to hopefully narrow down the cause of the issue:

1. Try to suspend from the TTY. If the system doesn’t freeze when you attempt to suspend from the TTY, then it’s probably graphics related (maybe something to do with your graphics driver or display server).
2. See if you can reproduce the same issue on the LTS kernel.

@AWalrus

Jan 28 22:32:52 pangolin systemd[1]: Reached target Sleep.
Jan 28 22:32:52 pangolin systemd[1]: Starting System Suspend...
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Successfully made thread 1408 of process 1374 owned by '1000' high priority at nice level 0.
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Supervising 7 threads of 4 processes of 1 users.
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Supervising 6 threads of 3 processes of 1 users.
Jan 28 22:32:52 pangolin systemd-sleep[6483]: Performing sleep operation 'suspend'...
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Supervising 6 threads of 3 processes of 1 users.
Jan 28 22:32:52 pangolin kernel: PM: suspend entry (s2idle)
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Successfully made thread 1408 of process 1374 owned by '1000' RT at priority 20.
Jan 28 22:32:52 pangolin rtkit-daemon[1079]: Supervising 7 threads of 4 processes of 1 users.
-- Boot 423200e78544499aa6d14fd2df3e10f9 --

The journal entries you posted do not contain anything informative about the error, likely because you forced shutdown your system with the power button. If it happens again, use the SysReq key to shutdown your system gracefully. After that, check the logs again.