Your message dated Thu, 15 Oct 2026 21:19:54 -0700
with message-id
<capyqnhdrv_hcb3udi2zixupesh26tu-+9jyueewi_4vh4+o...@mail.gmail.com>
and subject line Re: Bug#1131158: linux: regression on ThinkPad T14s Gen 4 AMD:
6.18.15 backports fails to reach S0i3 on s2idle, 6.12.74 works
has caused the Debian Bug report #1131158,
regarding linux: regression on ThinkPad T14s Gen 4 AMD: 6.18.15 backports fails
to reach S0i3 on s2idle, 6.12.74 works
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1131158: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1131158
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: linux-signed-amd64
Severity: important
Tags: upstream
Subject: linux-image-6.18.15+deb13-amd64: suspend via s2idle fails to reach
S0i3 on ThinkPad T14s Gen 4 AMD, while 6.12.74 works
Package: linux-image-6.18.15+deb13-amd64
Version: 6.18.15-1~bpo13+1
Severity: important
Tags: upstream
Dear Debian Kernel Team,
I am reporting what appears to be a suspend regression in the Debian backports
kernel on a Lenovo ThinkPad T14s Gen 4 AMD (type 21F8CTO1WW).
Summary
-------
On linux-image-6.18.15+deb13-amd64 (6.18.15-1~bpo13+1), suspend enters s2idle
but fails to reach S0i3 / deep low-power idle. The laptop "suspends", but the
fan keeps running and power draw remains high.
On the same machine, the Debian security kernel
linux-image-6.12.74+deb13+1-amd64 (6.12.74-2) works correctly: s2idle reaches
S0i3 successfully and the machine suspends properly.
System
------
- Model: Lenovo ThinkPad T14s Gen 4 AMD (21F8CTO1WW)
- CPU: AMD Ryzen 7 PRO 7840U
- BIOS before testing: 1.25
- BIOS updated during debugging via fwupd to: 1.29
- mem_sleep: [s2idle]
- The platform exposes S0/S4/S5 only; no "deep"/S3 is available
Regression comparison
---------------------
Working kernel:
- linux-image-6.12.74+deb13+1-amd64
- version 6.12.74-2
Failing kernel:
- linux-image-6.18.15+deb13-amd64
- version 6.18.15-1~bpo13+1
Both kernels were tested on the same machine and firmware.
Behavior on failing kernel (6.18.15-1~bpo13+1)
-----------------------------------------------
Relevant journal excerpts from the failing boot:
Linux version 6.18.15+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.18.15-1~bpo13+1
ACPI: PM: (supports S0 S4 S5)
Low-power S0 idle used by default for system suspend
systemd-sleep: Performing sleep operation 'suspend'...
PM: suspend entry (s2idle)
amd_pmc AMDI0009:00: Last suspend didn't reach deepest state
systemd-sleep: System returned from sleep operation 'suspend'
PM: suspend exit
During testing on 6.18, AMD PMC debugfs showed:
- S0ix Residency Time: 0
- Last S0i3 Status: Unknown/Fail
Observed user-visible effect:
- laptop appears suspended
- but fan keeps spinning
- opening the lid resumes the machine
Behavior on working kernel (6.12.74-2)
--------------------------------------
On 6.12.74+deb13+1-amd64, the same machine suspends correctly.
AMD PMC debugfs on the working 6.12 kernel reports:
- Last S0i3 Status: Success
- Time in S0i3: 9852905 us
- Residency Time: 9852905
This strongly suggests a regression between the two Debian kernel versions.
What was already tested
-----------------------
- BIOS updated from 1.25 to 1.29: no fix for 6.18 behavior
- acpi.ec_no_wakeup=1: no fix for 6.18 behavior
- Suspend tested with and without USB-C dock attached
- Suspend tested with dock-side USB/Thunderbolt wake settings adjusted
- The separate lid-close/logind issue was fixed independently and is unrelated
Potentially relevant hardware path
----------------------------------
This platform includes AMD Pink Sardine USB4/Thunderbolt controllers:
- 0000:c5:00.5
- 0000:c5:00.6
While debugging 6.18, amd_pmc debug output suggested USB4 activity remained
significant when suspend failed, but the regression remains reproducible even
after disconnecting the dock.
Installed package versions
--------------------------
- linux-image-6.18.15+deb13-amd64: 6.18.15-1~bpo13+1
- linux-image-6.12.74+deb13+1-amd64: 6.12.74-2
- amd64-microcode: 3.20250311.1
- firmware-linux / firmware-linux-nonfree: 20260110-1~bpo13+1
If needed, I can provide additional logs, but the key point is:
- 6.18 backports fails to reach S0i3 on suspend
- 6.12 on the same machine succeeds
Thanks.
-- System Information:
Debian Release: 13.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.74+deb13+1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
Version: 6.19.8-1~bpo13+1
Hi Salvatore,
Sorry for the slow follow-up. The issue is gone from 6.19 onwards, so I'm
closing this.
Same ThinkPad T14s Gen 4 AMD (21F8CTO1WW). I checked the kernel log of
every boot since the report for the amd_pmc "Last suspend didn't reach
deepest state" warning:
6.18.15-1~bpo13+1 6 suspends, all 6 failed to reach S0i3
6.19.8-1~bpo13+1 1 suspend, reached S0i3
6.19.11/6.19.13 (bpo) 98 suspends, no failures
7.0.7 .. 7.2.6 (bpo) 188 suspends, no failures
6.12.96 .. 6.12.111 150 suspends, no failures
On 7.2.6-1~bpo13+1 /sys/power/suspend_stats confirms it directly:
total_hw_sleep is 203,853 s over 8 suspends totalling about 56.6 h, so
essentially all of the suspended time was spent in hardware sleep.
Thanks,
Andrea
--- End Message ---
