Linux Power Management development
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: Fourhundred Thecat <400thecat@ik.me>,
	platform-driver-x86@vger.kernel.org
Cc: linux-pm@vger.kernel.org, Shyam-sundar.S-k@amd.com,
	hansg@kernel.org, ilpo.jarvinen@linux.intel.com,
	rafael@kernel.org
Subject: Re: [BUG] s2idle: unrecoverable sleep on ThinkPad P16s Gen 4 AMD, (Strix Point) when more than 16 logical CPUs are online
Date: Wed, 23 Sep 2026 11:41:55 -0500	[thread overview]
Message-ID: <99dcb462-5045-4fa7-9f6b-ee0f13ff96ab@amd.com> (raw)
In-Reply-To: <eafbba40-a10f-6a7f-54e6-b14d59ad1525@ik.me>



On 9/23/26 11:37, Fourhundred Thecat wrote:
> On 2026-09-23 18:20, Mario Limonciello wrote:
>>
>>
>> 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.
> 
> Tested, and it does not help.
> 
>    PlutonSecurityProcessor  Disable -> Enable
>    TpmSelection             DiscreteTPM2.0 -> PlutonTPM2.0
>    SecurityChip             Enable -> Active
> 
> With those set, IOMMU enabled, no IOMMU boot parameters and all 24 CPUs 
> online, the machine still does not wake.

That's interesting.  We'll have to see what the report shows if it's not 
the Pluton setting.

> 
> Worth noting what that test also covers: with Pluton selected the TPM 
> presents through the CRB interface (MSFT0101:00, status=15), and this 
> kernel has CONFIG_TCG_CRB=n. So during that suspend Linux had no TPM 
> driver bound at all -- no /sys/class/tpm, no /dev/tpm0, and the discrete 
> STM0925 was gone from the platform bus. Previously tpm_tis was bound to 
> STM0925:00. So this rules out the tpm_tis driver as a factor as well as 
> the Pluton policy.
> 
> Current state of what is ruled out, all with the IOMMU enabled and 24 
> CPUs online:
> 
>    amd_pmf                  initcall_blacklist=amd_pmf_driver_init no wake
>    amdxdna (NPU)            initcall_blacklist=amdxdna_pci_driver_init 
> no wake
>    TPM driver               no driver bound at all (Pluton/CRB, no 
> CONFIG_TCG_CRB)  no wake
>    Pluton policy            Pluton enabled, PlutonTPM2.0 no wake
>    interrupt remapping      intremap=off (verified: 0 IR- lines) no wake
>    DMA remapping            iommu=pt (verified: Passthrough, identity) 
> no wake
>    vAPIC / GA mode          amd_iommu_intr=legacy (verified) no wake
> 
> The only two things that let it wake are amd_iommu=off with all 24 CPUs, 
> or the IOMMU enabled with nr_cpus=16. 
> Offlining cpu16-23 by hotplug 
> after booting with all 24 does not work; they have to never be brought up.

No.  nr_cpus=16 wasn't a pass.  Don't treat it as such.  You didn't get 
to HW sleep.  Let's please not conflate changing NR CPUs.  Let's figure 
out what's wrong with all CPUs enabled and IOMMU enabled, and then peel 
it back if you need to turn off CPUs.

> 
> I am rebuilding now with CONFIG_DEBUG_FS, CONFIG_PM_DEBUG, 
> CONFIG_DYNAMIC_DEBUG and CONFIG_AMD_MP2_STB so I can run amd-s2idle and 
> send you the report from the working nr_cpus=16 configuration.

So you didn't run it yet?  I thought you said it failed.


  reply	other threads:[~2026-09-23 16:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 13:43 [BUG] s2idle: unrecoverable sleep on ThinkPad P16s Gen 4 AMD, (Strix Point) when more than 16 logical CPUs are online Fourhundred Thecat
2026-09-22 14:47 ` Mario Limonciello
2026-09-23  5:58   ` Fourhundred Thecat
2026-09-23 12:41     ` Mario Limonciello
2026-09-23 13:51       ` Fourhundred Thecat
2026-09-23 14:36         ` Mario Limonciello
2026-09-23 16:12           ` Fourhundred Thecat
2026-09-23 16:15             ` Mario Limonciello
2026-09-23 16:20               ` Mario Limonciello
2026-09-23 16:37                 ` Fourhundred Thecat
2026-09-23 16:41                   ` Mario Limonciello [this message]
2026-09-23 16:54                     ` Fourhundred Thecat
2026-09-23 16:59                       ` Mario Limonciello
2026-09-23 18:02                         ` Fourhundred Thecat
2026-09-23 18:11                           ` Mario Limonciello
2026-09-23 18:14                             ` Fourhundred Thecat
2026-09-23 18:25                               ` Mario Limonciello
2026-09-23 18:39                                 ` Fourhundred Thecat
2026-09-23 18:57                                   ` Mario Limonciello
2026-09-23 19:13                                     ` Fourhundred Thecat
2026-09-23 19:20                                       ` Mario Limonciello
2026-09-23 20:26                                         ` Fourhundred Thecat
2026-09-23 20:48                                           ` Fourhundred Thecat
2026-09-23 21:10                                             ` Mario Limonciello
2026-09-24  5:36                                               ` Fourhundred Thecat
2026-09-25  7:05                                               ` Fourhundred Thecat
2026-09-25 13:30                                                 ` Mario Limonciello
2026-09-26  4:13                                                   ` Fourhundred Thecat
2026-09-26 18:29                                                     ` Mario Limonciello
2026-09-29  5:43                                                       ` Fourhundred Thecat
2026-09-29  5:57                                                         ` Fourhundred Thecat
2026-09-29 13:37                                                           ` Mario Limonciello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99dcb462-5045-4fa7-9f6b-ee0f13ff96ab@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=400thecat@ik.me \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox