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

[Mario Limonciello <mario.limonciello@amd.com>]

On 9/23/26 11:15, Mario Limonciello wrote:
> 
> 
> On 9/23/26 11:12, Fourhundred Thecat wrote:
>> On 2026-09-23 16:36, Mario Limonciello wrote:
>>>
>>>
>>> Some other thoughts that might be the root cause based on other 
>>> historical issues.
>>>
>>> 1) Have you changed TPM policy or Pluton policy in BIOS setup?  What 
>>> did you change it from and to.
>>> 2) Have you enabled a storage security password?  If you disable it 
>>> does it help this issue?
>>> 3) Do you have WWAN in your device?  If you disable it does it help?
>>> 4) Does booting with `amd_iommu=off` help?
>>
>> 4) amd_iommu=off
>>
>> Yes, that fixes it. With amd_iommu=off and all 24 CPUs online, 
>> suspend/ resume works reliably.
>>
>> So this is not really a CPU count problem. nr_cpus=16 was only masking 
>> an IOMMU interaction. But narrowing it further was surprising: neither 
>> of the IOMMU's two functions is responsible on its own. All of the 
>> following were run with all 24 CPUs online, and I verified in each 
>> case that the parameter actually took effect:
>>
>>    amd_iommu=off            IOMMU off entirely                     WAKES
>>    intremap=off             IR off, DMA remapping on               no 
>> wake
>>    iommu=pt                 DMA passthrough, IR on                 no 
>> wake
>>    amd_iommu_intr=legacy    legacy GA mode, IR on, DMA on          no 
>> wake
>>
>> Verification for each:
>>
>>    intremap=off           /proc/interrupts went from 58 IR- lines to 0,
>>                           and irq 1 (i8042) is no longer IR-IO-APIC.
>>                           iommu still enabled, domain type Translated.
>>    iommu=pt               "iommu: Default domain type: Passthrough 
>> (set via
>>                           kernel command line)", all 40 PCI devices in
>>                           identity domains, IR still on (58 IR- lines).
>>    amd_iommu_intr=legacy  "AMD-Vi: Virtual APIC enabled" no longer 
>> printed,
>>                           only "AMD-Vi: Interrupt remapping enabled".
>>
>> So only disabling the IOMMU outright helps. Turning off interrupt 
>> remapping alone, bypassing DMA translation alone, or dropping out of 
>> vAPIC/GA mode all still hang.
>>
>> The CPU dependency is still there on top of that. With the IOMMU 
>> enabled, nr_cpus=16 works and 24 CPUs hangs. Offlining cpu16-23 by 
>> hotplug after booting with all 24 does not help; the CPUs have to 
>> never be brought up. cpu16-23 here are the second SMT thread of the 
>> eight Zen5c cores (APIC ids 17,19..31).
>>
>> Both conditions appear to be required: the IOMMU enabled, and more 
>> than 16 CPUs brought up at boot. Either one alone is fine.
>>
>>
>> 1) TPM / Pluton policy
>>
>> Current values:
>>
>>    TpmSelection            = DiscreteTPM2.0   (possible: 
>> DiscreteTPM2.0;PlutonTPM2.0)
>>    PlutonSecurityProcessor = Disable
>>    SecurityChip            = Enable
>>
>> The TPM that binds is a discrete STMicro part, tpm0 -> STM0925:00.
>>
>> I did change this. As I recall I disabled Microsoft Pluton, which 
>> moves the TPM selection off the PlutonTPM2.0 default onto the discrete 
>> part, so Enable -> Disable for Pluton and PlutonTPM2.0 -> 
>> DiscreteTPM2.0 for the selection. I will confirm the exact original 
>> values in setup. I have not yet tested whether restoring the Pluton 
>> default changes the behaviour, since the IOMMU result looked more 
>> promising.
>>
>>
>> 2) Storage security password
>>
>> None enrolled. HardDiskPasswordControl=Disable, and the HDD, NVMe, 
>> Admin, System and Power-on authentication slots all report 
>> is_enabled=0. BlockSIDAuthentication=Enable is the only non-default 
>> setting in that area. Nothing to disable, so nothing to test.
>>
>>
>> 3) WWAN
>>
>> Yes: Quectel [1eac:1007] at 0000:c4:00.0, attached over MHI, exposing 
>> wwan0. Its power/wakeup is enabled. Not yet tested with 
>> WirelessWANAccess disabled in BIOS.
>>
>>
>> so please suggest which test I should do next, now that we have more info
> 
> Of your above the most likely cause is PlutonSecurityProcessor = 
> Disable.  Please try to re-enable that and then try with IOMMU enabled.

BTW - what version of amd-s2idle didn't flag this?  I am surprised, we 
had a check for this that /should/ have failed prerequisites.