Framework 13 Ryzen 7040: Suspend and wakeup issues / amd_s2idle.py results

Framework Laptop 13 Linux
1

Currently I’m experiencing multiple issues that may be connected:

  1. Suspending my laptop in the evening with charged battery and no charger attached, it will not wake up from suspend next morning due to fully discharged battery
  2. Occasionally, when manually waking it up from suspend, it instead reboots

To inspect the latter, I use amd_s2idle.py by https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts/amd_s2idle.py

As root:

python amd_s2idle.py

using 10 seconds / cycle, 4 seconds in between and 10 cycles in total.

Regarding issue 1: After few successful cycles, amd_s2idle.py reports for all following cycles:
ERROR: :x: Did not reach hardware sleep state

Does not reaching hardware sleep state while “looking suspended” explain an increased battery drain?

Regarding issue 2: Chances are that within 10 cycles of the script my laptop will suspend, but when resuming automatically it will instead reboot.

Framework 13 Ryzen 5 7040
Firmware 3.06 (beta)
Arch Linux 6.12.8-1
No expansion modules except usb-c at slot 1

2 Likes
2

Turns out wifi module mt7921e is the cause of wakeup issues. Blocking wifi by rfkill before suspend / hibernate and unblocking after makes the framework wake up correctly.

See Framework Laptop 13 (AMD Ryzen 7040 Series) - ArchWiki

1 Like
3

I’m experiencing the second issue, and it is quite annoying. To the point when I put my laptop to sleep to go grab some water, go back, and instead of going back from sleep it reboots.
The battery drain issue is also here, although not as bad as you have, about 20% battery drain per night.

I’m attaching the amd_s2idle.py log, after 2-4 cycles it does not wake up from sleep, but instead reboots:

Knowing that the problem lies in the Wi-Fi module is of course good, but it would be great to also know why exactly this problem happens.

4

Oh, by the way I have Intel AX210 modem in my old laptop, so I can perform a swap, and theoretically the problem should go away.
But other than those wakeup issues, I don’t have any problems with the current MediaTek modem.

5

Maybe the MediaTek module also causes the increased battery drain, either by not suspending correctly by itself or by keeping the hole device from sleeping.

1 Like
6

Definetely could be.

7

Nope, that’s not MediaTek’s fault.

~$ lspci | grep AX
01:00.0 Network controller: Intel Corporation Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak] (rev 1a)

With modem swapped to intel, I still see about 20% battery drop per night of sleep.

8

Ok, still on Mediatek wifi module I experienced very little battery drop while suspended for the last two weeks (<1%/hour). Here’s what I did: rfkill block bluetooth and wifi before suspend and unblock afterwards. And instead of systemctl suspend I set suspend-then-hibernate as default.

See Arch wiki on how to automate this Framework Laptop 13 (AMD Ryzen 7040 Series) - ArchWiki

The cool thing is, suspend-then-hibernate suspends instantaniously, wakes up without delay within suspend state. After staying suspended for a while, system switches to hibernate automatically so I can leave the device suspended for days without further battery drain.

Edit: amd_s2idle.py still reports system not reaching hardware sleep state, but the framework stays cool during suspend and the reboot issue is gone also.

9

Update to latest version of the script (I have added some more checks recently) and post the full report.

1 Like
10

Indeed, amd_s2idle.py now reports hardware sleep cycles. Thank you @Mario_Limonciello
Although, I still have a systemd hook to block wifi+bluetooth enabled. Will run again without.

11

Second run without blocking wifi+bluetooth did work as well. See GitHub - baldrianbandit/logs: share log files

Also my framework did not reboot during 10 cycles like it did in january - yay! Is that due to updated firmware? Does amd_s2idle.py utilize system default suspend operation (in my case: suspend-then-hibernate)?

12

It does it without systemd by default. There is a logind argument if you want to suspend that way. But I’ll warn it’s often racy due to how systemd works.