Excessive power consumption during suspend on BIOS 3.18

Framework Laptop 13 Linux
1

Which Linux distro are you using?

NixOS

Which release version?
(if rolling release without a release version, skip this question)

Latest unstable channel

(If rolling release, last date updated?)

Today, March 3

Which kernel are you using?

6.19.5

Which BIOS version are you using?

3.18

Which Framework Laptop 13 model are you using? (AMD Ryzen™ AI 300 Series, AMD Ryzen™ 7040 Series, Intel® Core™ Ultra Series 1, 13th Gen Intel® Core™ , 12th Gen Intel® Core™, 11th Gen Intel® Core™)

AMD Ryzen 7040U

Recently, (since around the time that I updated my system firmware to BIOS 3.18), I have been noticing excessive power draw while my laptop is suspended in s2idle sleep (maybe something like 30-40% over 5 hours of suspend), with my laptop being warm to the touch when I remove it from my backpack.

The output of journalctl | grep “suspend” indicates that my system is indeed successfully entering sleep, and that it is not waking up from sleep prematurely:

Mar 03 00:36:31 laptop ModemManager[2762]: [sleep-monitor-systemd] system is about to suspend
Mar 03 00:36:33 laptop systemd-sleep[20362]: Performing sleep operation ‘suspend’…
Mar 03 00:36:33 laptop kernel: PM: suspend entry (s2idle)
Mar 03 12:21:52 laptop kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Mar 03 12:21:52 laptop kernel: queueing ieee80211 work while going to suspend
Mar 03 12:21:52 laptop kernel: pcieport 0000:00:08.3: quirk: disabling D3cold for suspend
Mar 03 12:21:52 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 12:21:52 laptop systemd-sleep[20362]: System returned from sleep operation ‘suspend’.
Mar 03 12:21:52 laptop kernel: PM: suspend exit
Mar 03 12:21:52 laptop systemd[1]: systemd-suspend.service: Deactivated successfully.
Mar 03 12:21:52 laptop systemd-logind[1367]: Operation ‘suspend’ finished.

If I try to switch my suspend method to s3/deep sleep, the system fails to suspend altogether:

systemd-sleep[20573]: Failed to put system to sleep. System resumed again: Invalid argument

Since the onset of this issue for me pretty much exactly coincides with my updating the system BIOS to 3.18, I am inclined to believe that this is the sole cause.

4 Likes
2

I am not sure if it is a kernel 6.19 issue or BIOS 3.18 issue. I saw the same message on my kernel log:

kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state

I did not notice it until I grab my laptop case, and it was warm so I knew something was off. I opened it, the power button is flashing white, so I assumed it is suspended but the whole machine felt warm.

3

Unless it’s a specific regression of 6.19.5, I’ve been on 6.19 for most of the last couple weeks with no sign of this problem.

4

Looking back in my logs, I do think the log message pointed out by @Kings is related to this problem, since I can confirm that the message was not present before this issue presented itself.

My system is on a tmpfs root, and I haven’t taken the steps to keep my fwupd logs across reboots (I do however keep journalctl logs), so I cannot say for certain the exact timestamp that I updated by BIOS to 3.18. However, from what I can tell the log message started around the same time I performed the update.

Just to confirm that this isn’t a kernel version issue, I have reverted my kernel to 6.18.15, and sure enough the log message is still there. Interestingly, I have a new log message that was not present when suspending on 6.19.5, but it is likely unrelated since it does not seem to be at all correlated with the other more symptomatic message:

Mar 04 10:41:50 laptop systemd[1]: systemd-suspend.service: Consumed 235ms CPU time over 4min 17.997s wall clock time, 2.1M memory peak, 5.3M read from disk, 20.6M written to disk.

5

I used amd-debug-tools to run amd-s2idle as suggested by a commenter on a post with a similar issue from last year.

Here is the output (md formatted)

6

I did a bit of digging… the log message appeared occasionally after Jan 4th on my machine, and the BIOS was 3.17, kernel 6.18.3 at the time. This log message appeared more after Feb 27th, with BIOS 3.18 and kernel 6.19.3. I am more confused now.

7

The message appeared twice in my logs before my update to BIOS 3.18, where it now appears on every suspend:

Dec 10 22:47:42 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Jan 07 12:04:28 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 02 19:47:00 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 02 21:20:31 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 12:21:52 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 13:10:16 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 13:17:39 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 14:17:36 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 14:45:27 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 15:53:36 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 16:06:56 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 16:57:24 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 18:03:59 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 19:29:24 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 19:38:29 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 19:48:40 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 23:01:15 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 03 23:38:00 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 08:48:51 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 10:04:56 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 10:08:36 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 10:28:06 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 10:41:50 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 10:59:22 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 10:59:36 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 10:59:50 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 11:01:37 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state
Mar 04 11:06:04 laptop kernel: amd_pmc AMDI0009:00: Last suspend didn’t reach deepest state

Looking back to where it appeared before, it seems like it was moments where I exited suspend immediately after entering it.

8

I’m on bios 3.17 and kernel 6.19.5 (NixOS), having the same issue. Last suspend didn’t reach deepest state in my journalctl when I close lid and suspect, laptop stays warm and battery drains.

9

It seems like maybe I am wrong that this is a BIOS issue.

After digging online a bit it seems like this could possibly be from a regression in kernel 6.19.4, which has been reverted in 6.19.6 (which hasn’t hit nixpkgs).

I’ve opened an issue in the FreeDesktop AMD driver issue tracker.

2 Likes
10

Relevant PR tracker for unstable which includes 6.19.6: PR tracker for #496567

1 Like
11

Impatient as I am, I patched my nixpkgs input to include this PR, and the problem seems to be resolved with 6.19.6 (at least looking at amd-s2idle and journal logs).

I will wait until I can test suspending for long periods before I confirm that this is resolved.

2 Likes
12

There’s a secondary issue in linux-firmware here, at least on Ryzen AI 300 models:

I opened linux-firmware: Fix hardware sleep regression in amdnpu firmware by andersk · Pull Request #496819 · NixOS/nixpkgs · GitHub to pull in the upstream fix amdnpu: Restore old NPU firmware for compatibility (!935) · Merge requests · kernel-firmware / Linux Firmware · GitLab.

13

Confirmed that upgrading to 6.19.6 did the trick for me also.

14

Issue as a whole is resolved for me after a day of use on 6.19.6.