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

Reply via email to