[BUG] s2idle: unrecoverable sleep on ThinkPad P16s Gen 4 AMD, (Strix Point) when more than 16 logical CPUs are online

[Fourhundred Thecat <400thecat@ik.me>]

Hi,

On a Lenovo ThinkPad P16s Gen 4 AMD (Ryzen AI 9 HX PRO 370, Strix 
Point), s2idle enters sleep normally but the machine can never be woken 
again and has to be force-powered-off. The trigger is the number of 
online logical CPUs: with all 24 threads online the failure is 100% 
reproducible, and limiting the kernel to 16 CPUs makes suspend/resume 
work reliably.

This platform has no S3 at all, so s2idle is the only suspend mode 
available.


Hardware
--------

   DMI product name    21RXS07D00
   DMI system version  ThinkPad P16s Gen 4 AMD
   BIOS                LENOVO R2XET40W (1.20), 05/26/2026
   CPU                 AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M
   CPU family          26, microcode 0xb204037
   Topology            12 cores / 24 threads
                       4x Zen5  (core_id 0-3)
                       8x Zen5c (core_id 8-15)

   ACPI: PM: (supports S0 S5)
   Low-power S0 idle used by default for system suspend
   /sys/power/mem_sleep -> [s2idle]      (no "deep"; DSDT has no _S3_)


Kernel
------

   6.18.51 x86_64, gcc (Debian 12.2.0-14+deb12u1) 12.2.0
   Custom monolithic build, no loadable module support.

   Relevant config:
     CONFIG_NR_CPUS=32
     CONFIG_SUSPEND=y, CONFIG_ACPI_SLEEP=y
     CONFIG_AMD_PMC=y, CONFIG_AMD_PMF=y, CONFIG_PINCTRL_AMD=y
     CONFIG_DRM_AMDGPU=y, CONFIG_DRM_ACCEL_AMDXDNA=y
     CONFIG_THINKPAD_ACPI=y, CONFIG_ACPI_EC=y


Reproducer
----------

   # echo mem > /sys/power/state

The system suspends cleanly. The ThinkPad power LED then shows the EC's 
slow breathing pattern, i.e. the ACPI LPS0 _DSM entry path ran and the 
EC considers the system asleep.

It never wakes again. Tried, with no effect:

   - opening the lid
   - any key on the internal keyboard
   - short press of the power button
   - clicking a USB mouse, with power/wakeup set to "enabled" on both
     the device (3-2) and its xHCI root hub (usb3)

The machine is also not reachable over the network while in this state, 
so it is not a case of resuming with a dead display. The only recovery 
is a ~10 s power button hold.

Wake sources are armed. From /proc/acpi/wakeup:

   XHC1  S3  *enabled   pci:0000:c5:00.4
   XHC0  S3  *enabled   pci:0000:c7:00.0
   XHC3  S3  *enabled   pci:0000:c7:00.3
   XHC4  S3  *enabled   pci:0000:c7:00.4
   NHI0  S3  *enabled   pci:0000:c7:00.5
   NHI1  S3  *enabled   pci:0000:c7:00.6
   LID   S4  *enabled   platform:PNP0C0D:00
   SLPB  S3  *enabled   platform:PNP0C0E:00

and platform/i8042/serio0 power/wakeup is "enabled".


Bisect
------

The regression was introduced by raising CONFIG_NR_CPUS:

   CONFIG_NR_CPUS=16   suspend/resume works
   CONFIG_NR_CPUS=32   suspend enters, never wakes    (100% reproducible)

Booting the *same* CONFIG_NR_CPUS=32 kernel with nr_cpus=16 on the 
command line also works. So the trigger is the number of online logical 
CPUs at suspend time, not anything else in the build.

NR_CPUS=16 is of course wrong for this CPU -- it silently leaves 8 of 
the 24 threads unused -- so this is a workaround, not a fix.

At nr_cpus=16 the kernel brings up every core's primary thread plus only 
the Zen5 SMT siblings:

   cpu0-3     core_id 0-3     Zen5   primary threads
   cpu4-11    core_id 8-15    Zen5c  primary threads
   cpu12-15   core_id 0-3     Zen5   SMT siblings
   (absent)   core_id 8-15    Zen5c  SMT siblings

The 8 CPUs that are absent in the working configuration are exactly the 
SMT siblings of the 8 Zen5c cores. I have not yet narrowed down whether 
the threshold is exactly 17 CPUs or specifically the Zen5c siblings; I 
can bisect nr_cpus= further if that is useful.


Ruled out
---------

None of these had any effect (still hangs with all 24 CPUs online):

   initcall_blacklist=amd_pmf_driver_init
   initcall_blacklist=amdxdna_pci_driver_init
   runtime unbind of amdxdna, amd-pmf and tpm_tis before suspending


Possibly relevant
-----------------

After a *successful* suspend/resume at nr_cpus=16:

   /sys/power/suspend_stats/success         1
   /sys/power/suspend_stats/total_hw_sleep  0
   /sys/power/suspend_stats/last_hw_sleep   0
   /sys/power/suspend_stats/max_hw_sleep    18446744073709551615

so no hardware sleep residency is recorded even in the configuration 
that works. It may be that the working case simply never reaches 
hardware s0i3, and that the failure appears only once the SoC does enter 
it. I could not confirm this: this build has CONFIG_DEBUG_FS=n and 
CONFIG_PM_DEBUG=n, so I have no /sys/kernel/debug/amd_pmc/s0ix_stats and 
no /sys/power/pm_test. I can rebuild with those enabled and re-run 
whatever you would like to see.

Also, the 21RX series has no entry in the fwbug_list DMI table in 
drivers/platform/x86/amd/pmc/pmc-quirks.c; the Lenovo entries there stop 
at the 2021-era ThinkPads and some 2023 IdeaPads.

Happy to run further tests, bisect nr_cpus= to the exact threshold, or 
provide full dmesg, ACPI tables or the kernel config.

Thanks,