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 13:39, Fourhundred Thecat wrote:
> On 23/09/2026 20.25, Mario Limonciello wrote:
> 
>>
>> Can you please share your kernel log from this run as well?  It seems
>> that your distro dmesg tool didn't pick it up in the tool run.
>>
>> And can I please see dmesg from a run with amd_iommu=on too.
>>
>>>    🚦 DMI data was not setup
>>
>> What is up with the missing data here?
>>
>> Does your BIOS offer anything to control D3 behavior for the storage?
>>
>> And this other point I mentioned: another useful data point will be
>> whether this can reproduce on 7.3-rc4 with IOMMU enabled to rule out a
>> backport issue.
> 
>> Can you please share your kernel log from this run as well?
> 
> Attached as dmesg-iommu-off.txt (full log, 1082 lines, amd_iommu=off, 24
> CPUs, the cycle that succeeded). The suspend/resume portion:
> 
>    PM: suspend entry (s2idle)
>    Filesystems sync: 0.010 seconds
>    Freezing user space processes
>    Freezing user space processes completed (elapsed 0.001 seconds)
>    OOM killer disabled.
>    Freezing remaining freezable tasks
>    Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
>    PM: Triggering wakeup from IRQ 9
>    ACPI: PM: Rearming ACPI SCI for wakeup
>    amd_pmc: SMU idlemask s0i3: 0xffff9afd
>    PM: Triggering wakeup from IRQ 9
>    ACPI: PM: Rearming ACPI SCI for wakeup
>    PM: Triggering wakeup from IRQ 9
>    amd_pmc: SMU idlemask s0i3: 0xffff9abd
>    ACPI: PM: Rearming ACPI SCI for wakeup
>    amd_pmc: SMU idlemask s0i3: 0xffff9abd
>    PM: Triggering wakeup from IRQ 9
>    PM: Triggering wakeup from IRQ 7
>    ACPI: PM: Wakeup after ACPI Notify sync
>    OOM killer enabled.
>    Restarting tasks: Starting
>    Restarting tasks: Done
>    PM: suspend exit
> 
> For reference, IRQ 9 is the ACPI SCI and IRQ 7 is pinctrl_amd, so the
> SCI fires and re-arms several times and the actual wake arrives through
> the AMD GPIO controller.
> 
>> And can I please see dmesg from a run with amd_iommu=on too.
> 
> I cannot produce one. With the IOMMU enabled the machine never resumes,
> so the ring buffer is lost to the forced power cycle. Streaming it out
> does not work either: dmesg -w and sshd are both frozen by the freezer,
> so over ssh the log stops at
> 
>    PM: suspend entry (s2idle)
>    Filesystems sync: 0.011 seconds
> 

I don't need the full run, I'm looking for how it sets up differently.

I am specifically expecting the message from 
51c33f333bbf7bdb6aa2a327e3a3e4bbb2591511 to come up and want to confirm 
that.

> and nothing after that ever leaves the machine. There is no serial port
> on this laptop, and since it hangs rather than panics, pstore captures
> nothing.
> 
> What I can send instead is a full kernel log with the IOMMU enabled
> using /sys/power/pm_test=platform, which runs the whole suspend path
> including LPS0 _DSM entry and returns without entering the idle loop.
> That gives you every device callback and the platform prepare with the
> IOMMU active. I will send it in a follow-up unless you would rather have
> something else.
> 
>> Uh, the hardware does support a wakealarm.  You might have disabled it
> in your kernel.
> 
> I checked, and the relevant options are all enabled:
> 
>    CONFIG_RTC_CLASS=y
>    CONFIG_RTC_DRV_CMOS=y
>    CONFIG_RTC_INTF_SYSFS=y
>    CONFIG_RTC_INTF_DEV=y
>    CONFIG_HPET=y
>    CONFIG_HPET_TIMER=y
>    CONFIG_HPET_EMULATE_RTC=y
> 
> What happens at boot is:
> 
>    hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
>    hpet0: 3 comparators, 32-bit 14.318180 MHz counter
>    clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 133484873504 ns
>    rtc_cmos PNP0B00:00: error -ENXIO: IRQ index 0 not found
>    rtc_cmos PNP0B00:00: RTC can wake from S4
>    rtc_cmos PNP0B00:00: registered as rtc0
> 
> and /proc/driver/rtc reports HPET_emulated: no.
> 
> As far as I can follow it, HPET is registered as a clocksource only and
> legacy replacement is never enabled, so is_hpet_enabled()
> (is_hpet_capable() && hpet_legacy_int_enabled) is false. That makes
> use_acpi_alarm_quirks() return at its "if (!is_hpet_enabled()) return;"
> check, so use_acpi_alarm stays false, and use_hpet_alarm() is false too.
> ACPI does not give PNP0B00 an interrupt resource, so
> is_valid_irq(rtc_irq) fails and cmos_do_probe() takes the else branch
> that does clear_bit(RTC_FEATURE_ALARM, ...), which is why there is no
> wakealarm attribute.

I think you're missing commit e9f850ba66cdf6b77fb4f005e46c4b605c4de434.

> 
>>   🚦 DMI data was not setup
>> What is up with the missing data here?
> 
> CONFIG_DMIID is not set in my config, so /sys/class/dmi/id does not
> exist. DMI itself is scanned normally:
> 
>    DMI: LENOVO 21RXS07D00/21RXS07D00, BIOS R2XET40W (1.20 ) 05/26/2026
> 
> so dmi_check_system() quirks do apply. I will enable CONFIG_DMIID in the
> next build so the tool stops reporting it.
> 
>> Does your BIOS offer anything to control D3 behavior for the storage?
> 
> No. I dumped all 96 attributes exposed by think-lmi and there is nothing
> for storage power management or D3. The only storage related entries are
> HardDiskPasswordControl and BlockSIDAuthentication, both access control
> rather than power.

I don't know for sure if Think LMI will export all BIOS options in the 
BIOS GUI.

> 
>> whether this can reproduce on 7.3-rc4 with IOMMU enabled to rule out a
> backport issue
> 
> i will try to test 7.3-rc4  as you suggest

OK.