[RESPONDED] Inconsistent resume from suspend [Linux, AMD]

Framework Laptop 13 Linux
1

Fedora 39
Framework 13 - AMD 7040

I’m having inconsistent issues waking from suspend, occasionally it works properly but the majority of the time my laptop resumes as if from a fresh reboot.

journalctl at least shows that the system is going into S2 sleep, however nothing in my logs shows any reason for the failure to come back out of sleep (at least to my untrained eye). No change in behavior when on battery or connected to power.

This is pretty much a default installation of Fedora 39, with the tweaks suggested by the Framework guides. Installation is probably about 3 months old, but is fully updated.

First few lines from journalctl -b -1 -r 

Mar 05 21:41:32 amidala kernel: PM: suspend entry (s2idle)
Mar 05 21:41:32 amidala systemd-sleep[17736]: Entering sleep state 'suspend'...
Mar 05 21:41:32 amidala systemd[1]: Starting systemd-suspend.service - System S>
Mar 05 21:41:32 amidala systemd[1]: Reached target sleep.target - Sleep.
1 Like
2

Could post the lines from the journal when a full suspend and resume cycle is done. The cutout you posted seems fine. But more details would be great and are appreciated. I run debian with a custom 6.7 kernel and have no problems with suspend and resume. Even before I installed the custom kernel with kernel 6.5 I had no problems, only the occasional white screen with some colored cubes.

3

Welcome to the community! If you are fully updated, followed our guide carefully, then I would try the following for testing purposes:

  • Detach from everything except power. No external displays or peripherals.

  • Suspend from the pull down menu in the upper right corner.

  • Try waking using lower left corner (click it) of the touchpad. This should wake the laptop.

4

I generally run without anything attached or only power. Suspending from menu or resuming from the touchpad do not seem to have an effect.

Notably this is an intermittent issue, resume sometimes works. I’ve noticed that it usually works within the first few minutes of being suspended, but not typically after about 10 minutes (although occasionally it will resume just fine after being suspended all night).

The battery is not low, and it is often plugged into power when a resume fails. The lowest battery percentage I’ve seen wtih a failed resume was near 40%.

5

So there’s good news and bad news.
First the Good News:

Now the bad news:
It may not be implemented until kernel 6.10 and this doesn’t solve our problem, it only makes our problem more solvable.

6

Tested this again, Fedora 30. Clicking the bottom left (for a left click) of the touchpad on the FW13 AMD, woke up. I will test additional suspend scenarios, but it would be interesting to see what your logs indicate is happening. Namely, grep resume.

7

I’m on Fedora 39, currently running kernel 6.7.7-200 from the Fedora repos. Annoyingly, it seems to be working fine at the moment. No kernel upgrades since I initially posted, as well as no configuration changes. I have not idea why it is suddenly working well.

Successul resume (two in this case):

~$ journalctl -b -0 | grep resume
Mar 12 19:58:24 amidala kernel: amdgpu 0000:c1:00.0: amdgpu: SMU is resumed successfully!
Mar 12 19:58:24 amidala kernel: PM: resume devices took 0.369 seconds
Mar 12 19:58:24 amidala bluetoothd[1020]: Controller resume with wake event 0x0
Mar 12 20:49:58 amidala kernel: amdgpu 0000:c1:00.0: amdgpu: SMU is resumed successfully!
Mar 12 20:49:58 amidala kernel: PM: resume devices took 0.372 seconds
Mar 12 20:49:58 amidala bluetoothd[1020]: Controller resume with wake event 0x0 here

Unsuccessful resumes don’t have any relevant log entries, which clearly makes this a more difficult issue to troubleshoot.

8

I was having this exact same issue once or twice a day. I’m on day 3 of kernel 6.7.9-200 (no other changes) and have not seen it again with many lid closes and suspends of varying duration (long and short). Perhaps too early to call it fixed but so far, so good.

9

I’ve been having this issue ever since I got my laptop, and while I haven’t figured out the cause, I have figured out a consistent way to replicate it. If I insert an expansion card while the system is suspended, the system will consistently reboot instead of waking up, with no traces in the logs, as if the power was simply cut off. So perhaps it is something to do with expansion cards?

But I’ve also had this happen with no expansion cards installed, so maybe not.

10

I think I’ve found the culprit - I uninstalled TLP (apparently known to interfere with AMD suspend) and now my laptop has managed to stay online for days at a time, with no suspend issues whatsoever. power-profiles-daemon seems to be fine.