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/25/26 02:05, Fourhundred Thecat wrote:
> resolved by resetting BIOS to factory defaults
> 
> after that, I tried painstakingly to enable/disable one by one
> 
> The cause is two BIOS settings, and the reason it took so long to find 
> is that they are independently sufficient:
> 
>    AmdVt (AMD virtualization)        Disable  -> breaks s2idle wake
>    PlutonSecurityProcessor           Disable  -> breaks s2idle wake
> 
> Either one alone is enough. Both must be enabled for the machine to 
> resume. The full matrix, all with the IOMMU enabled and 24 CPUs online:
> 
>    AmdVt      Pluton     result
>    Enable     Disable    no wake
>    Disable    Enable     no wake
>    Disable    Disable    no wake
>    Enable     Enable     wakes normally
> 
> I had both disabled.
> It also explains the confusing bisect: when I tested AmdVt=Enable with 
> everything else at my settings it still hung, and when I tested 
> Pluton=Enable with everything else at my settings it still hung, so I 
> eliminated both. Each test only showed the setting was not necessary; 
> neither showed it was not sufficient. With two independent triggers 
> those observations are both true at once and single-setting elimination 
> gives nothing.
> 
> So amd_iommu=off and nr_cpus=16 were both masking this rather than 
> telling us anything about the kernel.

Well this is a great outcome.  Would you mind opening a pull request to 
amd-debug-tools and adding a case to this to test for this issue?  That 
would help anyone else that encounters this in the future and save us 
effort drilling down again.

You should be able to add a new check that verified the value of these 
BIOS settings using the think-lmi driver sysfs interface.
My thought on the logic would be something like this:

1) Check whether think-lmi directory exists, skip the check if it doesn't.
2) Check whether both of those attributes exist.  If they don't, skip 
the check.
3) Check the values of both of those attributes.  If there is a failure 
report it.  If it's a pass report it.

It can generally apply to all Lenovo systems that offer these settings 
then (It's more likely a "generic" BIOS bug).

> 
> this is clearly a Lenovo BIOS bug. should this be reported to them ?

Before you report this to them, can you diff some acpidumps from the two 
changes that break things?

I would have "expected" that turning off this AmdVt BIOS option stopped 
the IVRS table from being created, but that seems not to be the case.

I just wonder if we should be keying off anything else in Linux for this 
case to avoid the issue.