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

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

[Fourhundred Thecat]

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,

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

[Mario Limonciello]

On 9/22/26 08:43, Fourhundred Thecat wrote:
> 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,

Try this patch.

https://lore.kernel.org/all/20260826171537.4167367-1-Vishal.Badole@amd.com/

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

[Fourhundred Thecat]

On 2026-09-22 16:47, Mario Limonciello wrote:
> 
> 
> On 9/22/26 08:43, Fourhundred Thecat wrote:
>> 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,
> 
> Try this patch.
> 
> https://lore.kernel.org/all/20260826171537.4167367-1-Vishal.Badole@amd.com/

I don't see how that patch is relevant to my issue or my kernel version 
6.18. There is no cluster code in lib/group_cpus.c and the patch cannot 
be applied.

My report is about the machine never leaving s2idle when more than 16 
CPUs are online.

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

[Mario Limonciello]

On 9/23/26 00:58, Fourhundred Thecat wrote:
> On 2026-09-22 16:47, Mario Limonciello wrote:
>>
>>
>> On 9/22/26 08:43, Fourhundred Thecat wrote:
>>> 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,
>>
>> Try this patch.
>>
>> https://lore.kernel.org/all/20260826171537.4167367-1- 
>> Vishal.Badole@amd.com/
> 
> I don't see how that patch is relevant to my issue or my kernel version 
> 6.18. There is no cluster code in lib/group_cpus.c and the patch cannot 
> be applied.
> 
> My report is about the machine never leaving s2idle when more than 16 
> CPUs are online.

Re-reading your email I don't think it will help.

Running CONFIG_NR_CPUS less than the physical number of CPUs is 
effectively the same as booting with physical number of CPUs and then 
offlining them.  We've found some problems with offlining cores breaking 
s2idle and it being fixed by that patch.

But your issue is different I see; you don't even get to HW sleep ever.

Can you please share your amd-s2idle report?

Thanks,

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

[Fourhundred Thecat]

On 2026-09-23 14:41, Mario Limonciello wrote:
> 
> 
> On 9/23/26 00:58, Fourhundred Thecat wrote:
>> On 2026-09-22 16:47, Mario Limonciello wrote:
>>>
>>>
>>> On 9/22/26 08:43, Fourhundred Thecat wrote:
>>>> 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,
>>>
>>> Try this patch.
>>>
>>> https://lore.kernel.org/all/20260826171537.4167367-1- 
>>> Vishal.Badole@amd.com/
>>
>> I don't see how that patch is relevant to my issue or my kernel 
>> version 6.18. There is no cluster code in lib/group_cpus.c and the 
>> patch cannot be applied.
>>
>> My report is about the machine never leaving s2idle when more than 16 
>> CPUs are online.
> 
> Re-reading your email I don't think it will help.
> 
> Running CONFIG_NR_CPUS less than the physical number of CPUs is 
> effectively the same as booting with physical number of CPUs and then 
> offlining them.  We've found some problems with offlining cores breaking 
> s2idle and it being fixed by that patch.
> 
> But your issue is different I see; you don't even get to HW sleep ever.
> 
> Can you please share your amd-s2idle report?
> 
> Thanks,

Booting with all 24 CPUs and then offlining cpu16-23 via
/sys/devices/system/cpu/cpuN/online before suspending does NOT help: the
machine still never wakes. Only booting with nr_cpus=16 works. The CPUs 
have to never
be brought up at all.

cpu16-23 here are the second SMT thread of the eight Zen5c cores
(APIC ids 17,19..31). With nr_cpus=16 the kernel brings up every core's
primary thread plus only the four Zen5 siblings.

On the amd-s2idle report: I cannot produce one for the failing
configuration. The machine never resumes, so the script never gets to
write its output, and there is no pstore to recover it from.

Or did you mean to generate the report in the working nr_cpus=16 boot ?

also, I should explain that I am on a sysvinit system with no systemd, 
so the script's journal-based log collection will not work. Is there a 
dmesg or logfile fallback, or should I capture the kernel log separately 
and attach it?

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

[Mario Limonciello]

> Booting with all 24 CPUs and then offlining cpu16-23 via
> /sys/devices/system/cpu/cpuN/online before suspending does NOT help: the
> machine still never wakes. Only booting with nr_cpus=16 works. The CPUs 
> have to never
> be brought up at all.
> 
> cpu16-23 here are the second SMT thread of the eight Zen5c cores
> (APIC ids 17,19..31). With nr_cpus=16 the kernel brings up every core's
> primary thread plus only the four Zen5 siblings.
> 
> On the amd-s2idle report: I cannot produce one for the failing
> configuration. The machine never resumes, so the script never gets to
> write its output, and there is no pstore to recover it from.
> 
> Or did you mean to generate the report in the working nr_cpus=16 boot ?

If it doesn't work during resume, that's fine to run it with nr_cpus=16; 
I want to see the prerequisites it reports.

> 
> also, I should explain that I am on a sysvinit system with no systemd, 
> so the script's journal-based log collection will not work. Is there a 
> dmesg or logfile fallback, or should I capture the kernel log separately 
> and attach it?

You can capture kernel log separately if the tool can't fetch it.  It 
will try to capture and use 'dmesg' as a fallback but that doesn't work 
on all distros.

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?

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

[Fourhundred Thecat]

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

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

[Mario Limonciello]

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.

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

[Mario Limonciello]

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.

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

[Fourhundred Thecat]

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.

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.

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.

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

[Mario Limonciello]

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.

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

[Fourhundred Thecat]

On 2026-09-23 18:41, Mario Limonciello wrote:
> 
> 
> 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.
> 

 > 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.

Agreed, I will drop it from the framing.

That does leave a gap in my own data which I should close: I never 
measured whether amd_iommu=off reaches hardware sleep either. I only 
recorded total_hw_sleep=0 for the nr_cpus=16 case and did not check the 
counter after an amd_iommu=off resume. If that is also 0 then nothing on 
this machine has ever reached s0i3, and the wake failure is a 
second-order effect rather than the thing to chase. I will measure it.

I would also like to confirm the counter is meaningful here before 
drawing conclusions from it. max_hw_sleep reads 18446744073709551615, 
which looks like an unpopulated value, so total_hw_sleep=0 may be a 
reporting gap rather than a real zero. With CONFIG_DEBUG_FS and 
CONFIG_AMD_MP2_STB in the new build I can read 
/sys/kernel/debug/amd_pmc/s0ix_stats directly instead of inferring it 
from suspend_stats.

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

Correct, I have not run amd-s2idle yet. The running kernel was built 
with CONFIG_DEBUG_FS=n, CONFIG_PM_DEBUG=n, CONFIG_DYNAMIC_DEBUG=n and 
CONFIG_AMD_MP2_STB=n, so there was no /sys/kernel/debug/amd_pmc for the 
tool to read and nothing for it to report. What failed was the suspend 
itself, not the tool.

The rebuild with those four enabled is running now. I will come back 
with the amd-s2idle report, plus the hardware sleep residency with the 
IOMMU enabled and with amd_iommu=off, both with all 24 CPUs online.

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

[Mario Limonciello]

On 9/23/26 11:54, Fourhundred Thecat wrote:
> On 2026-09-23 18:41, Mario Limonciello wrote:
>>
>>
>> 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.
>>
> 
>  > 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.
> 
> Agreed, I will drop it from the framing.
> 
> That does leave a gap in my own data which I should close: I never 
> measured whether amd_iommu=off reaches hardware sleep either. I only 
> recorded total_hw_sleep=0 for the nr_cpus=16 case and did not check the 
> counter after an amd_iommu=off resume. If that is also 0 then nothing on 
> this machine has ever reached s0i3, and the wake failure is a second- 
> order effect rather than the thing to chase. I will measure it.
> 
> I would also like to confirm the counter is meaningful here before 
> drawing conclusions from it. max_hw_sleep reads 18446744073709551615, 
> which looks like an unpopulated value, so total_hw_sleep=0 may be a 
> reporting gap rather than a real zero. With CONFIG_DEBUG_FS and 
> CONFIG_AMD_MP2_STB in the new build I can read /sys/kernel/debug/ 
> amd_pmc/s0ix_stats directly instead of inferring it from suspend_stats.

I don't care about max_hw_sleep.  It's a hardcoded value.

https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-power-suspend-stats-max-hw-sleep

> 
>  > So you didn't run it yet?  I thought you said it failed.
> 
> Correct, I have not run amd-s2idle yet. 


That should have been your first debugging step.

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

[Fourhundred Thecat]

On 2026-09-23 18:59, Mario Limonciello wrote:
> 
> 
> On 9/23/26 11:54, Fourhundred Thecat wrote:
>> On 2026-09-23 18:41, Mario Limonciello wrote:
>>>
>>>
>>> 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.
>>>
>>
>>  > 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.
>>
>> Agreed, I will drop it from the framing.
>>
>> That does leave a gap in my own data which I should close: I never 
>> measured whether amd_iommu=off reaches hardware sleep either. I only 
>> recorded total_hw_sleep=0 for the nr_cpus=16 case and did not check 
>> the counter after an amd_iommu=off resume. If that is also 0 then 
>> nothing on this machine has ever reached s0i3, and the wake failure is 
>> a second- order effect rather than the thing to chase. I will measure it.
>>
>> I would also like to confirm the counter is meaningful here before 
>> drawing conclusions from it. max_hw_sleep reads 18446744073709551615, 
>> which looks like an unpopulated value, so total_hw_sleep=0 may be a 
>> reporting gap rather than a real zero. With CONFIG_DEBUG_FS and 
>> CONFIG_AMD_MP2_STB in the new build I can read /sys/kernel/debug/ 
>> amd_pmc/s0ix_stats directly instead of inferring it from suspend_stats.
> 
> I don't care about max_hw_sleep.  It's a hardcoded value.
> 
> https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-power-suspend-stats-max-hw-sleep
> 
>>
>>  > So you didn't run it yet?  I thought you said it failed.
>>
>> Correct, I have not run amd-s2idle yet. 
> 
> 
> That should have been your first debugging step.

Rebuilt with CONFIG_DEBUG_FS, CONFIG_PM_DEBUG, CONFIG_DYNAMIC_DEBUG, 
CONFIG_AMD_MP2_STB, CONFIG_X86_MSR and a larger log buffer, and removed 
CONFIG_RANDSTRUCT so the kernel is no longer tainted. Prerequisites now 
pass. Run below is with all 24 CPUs online, IOMMU enabled, no IOMMU boot 
parameters.

amd-s2idle prerequisites:

   AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (family 1a model 24)
   DMI data was not setup
   Debian GNU/Linux 12 (bookworm)
   Kernel 6.18.51
   Battery BAT0 (SMP 5B11H56412) is operating at 102.35% of design
   ASPM policy set to 'default'
   GPIO driver `pinctrl_amd` available
   PMC driver `amd_pmc` loaded (Program 11 Firmware 93.23.0)
   PCIe hotplug driver `pciehp` loaded
   USB3 driver `xhci_hcd` bound to 0000:c5:00.4, 0000:c7:00.0, 
0000:c7:00.3, 0000:c7:00.4
   USB4 driver `thunderbolt` bound to 0000:c7:00.5, 0000:c7:00.6
   System is configured for s2idle
   GPU driver `amdgpu` bound to 0000:c5:00.0
   PC6 and CC6 enabled
   SMT enabled
   IOMMU properly configured
   ACPI FADT supports Low-power S0 idle
   Logs are provided via dmesg, timestamps may not be accurate over 
multiple cycles
   LPS0 _DSM enabled
   WLAN driver `mt7925e` bound to 0000:c2:00.0
   No RTC device found, please manually wake system

Two notes on the remaining warnings. The DMI one is a false positive 
here: this kernel has CONFIG_DMIID=n so /sys/class/dmi/id does not 
exist, but DMI itself is scanned normally ("DMI: LENOVO 
21RXS07D00/21RXS07D00, BIOS R2XET40W (1.20 ) 05/26/2026") and 
dmi_check_system() quirks do apply. The RTC one is real: this machine 
reports "rtc_cmos PNP0B00:00: error -ENXIO: IRQ index 0 not found", so 
RTC_FEATURE_ALARM is cleared and there is no wakealarm to program. 
use_acpi_alarm_quirks() should match here (AMD, BIOS year 2026, HPET 
enabled) but the feature bit is cleared purely on IRQ absence, so it 
cannot take effect.

I cannot give you a report file for the failing configuration, because 
the tool writes it after resume and the machine never resumes. The 
kernel log also cannot be captured past the freezer: dmesg -w over ssh 
stops as soon as user space is frozen. All I get is:

   PM: suspend entry (s2idle)
   Filesystems sync: 0.011 seconds

There is no serial port on this machine and no panic, so pstore captures 
nothing either.

What is more useful is a /sys/power/pm_test bisect, all with 24 CPUs and 
the IOMMU enabled:

   freezer     pass
   devices     pass, every device callback returned 0, resume of devices 
complete after 206.186 msecs
   platform    pass, resume of devices complete after 261.566 msecs

processors and core are rejected for s2idle ("PM: Unsupported test mode 
for suspend to idle, please choose none/freezer/devices/platform"), so 
platform is the deepest available.

platform covers the ACPI platform prepare including LPS0 _DSM entry and 
returns before entering the idle loop. So the entire software suspend 
path is clean: freezing, every device suspend/resume callback, and the 
platform prepare all work. The only step not covered by pm_test is 
entering and exiting hardware s0i3, and that is where it hangs.

Combined with "PC6 and CC6 enabled" passing, the cores are able to reach 
the required C-state. And amd_iommu=off with the same 24 CPUs makes the 
machine wake normally, while intremap=off, iommu=pt and 
amd_iommu_intr=legacy all still hang.

Baseline before the failing suspend, from debugfs:

   /sys/kernel/debug/amd_pmc/s0ix_stats
     S0ix Entry Time: 0
     S0ix Exit Time: 0
     Residency Time: 0
   /sys/kernel/debug/amd_pmc/smu_fw_info
     Table Version: 0
     Hint Count: 0
     Last S0i3 Status: Unknown/Fail

I will boot amd_iommu=off next and send the same counters plus a full 
amd-s2idle report from a cycle that actually resumes, so you can see 
whether that configuration reaches hardware sleep or is simply failing 
to get there in a way that happens to stay recoverable.

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

[Mario Limonciello]

On 9/23/26 13:02, Fourhundred Thecat wrote:

< snip noisy LLM interactions >

> I will boot amd_iommu=off next and send the same counters plus a full 
> amd-s2idle report from a cycle that actually resumes, so you can see 
> whether that configuration reaches hardware sleep or is simply failing 
> to get there in a way that happens to stay recoverable.

Please attach it when you have it.  Hopefully something stands out to me 
what could be wrong with the IOMMU here.

Another useful data point will be whether this can reproduce on 7.3-rc4 
with IOMMU enabled to rule out a backport issue.

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

[Fourhundred Thecat]

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

On 2026-09-23 20:11, Mario Limonciello wrote:
> 
> 
> On 9/23/26 13:02, Fourhundred Thecat wrote:
> 
> < snip noisy LLM interactions >
> 
>> I will boot amd_iommu=off next and send the same counters plus a full 
>> amd-s2idle report from a cycle that actually resumes, so you can see 
>> whether that configuration reaches hardware sleep or is simply failing 
>> to get there in a way that happens to stay recoverable.
> 
> Please attach it when you have it.  Hopefully something stands out to me 
> what could be wrong with the IOMMU here.
> 
> Another useful data point will be whether this can reproduce on 7.3-rc4 
> with IOMMU enabled to rule out a backport issue.


amd_iommu=off with all 24 CPUs online does reach hardware sleep. Full 
amd-s2idle report attached; the relevant parts:

/sys/kernel/debug/amd_pmc/smu_fw_info after the cycle:

   Table Version: 3
   Hint Count: 1
   Last S0i3 Status: Success
   Time (in us) to S0i3: 427925
   Time (in us) in S0i3: 2066740
   Time (in us) to resume from S0i3: 255153

/sys/kernel/debug/amd_pmc/s0ix_stats:

   S0ix Entry Time: 11245218037
   S0ix Exit Time: 11337753680
   Residency Time: 1927825

   /sys/power/suspend_stats/last_hw_sleep:  2066740
   /sys/power/suspend_stats/total_hw_sleep: 2066740
   /sys/power/pm_wakeup_irq: 9

amd-s2idle summary line:

   Start Time           Duration  Hardware Sleep  Battery Delta  Average 
Power  Wake Interrupt
   2026-09-23 20:07:28  0:00:07   28.57%          -0.02%         -10.29W 
        Disabled interrupt (acpi)

The only failure it reports for the cycle is "Userspace wasn't asleep at 
least 0:00:30", because I woke the machine by hand after 7 seconds. 
There is no RTC wakealarm on this machine, so every cycle has to be 
woken manually. Not a real failure.

So this settles the question you raised about nr_cpus=16. You were right 
that it was never a pass: it showed total_hw_sleep=0 and never reached 
s0i3. amd_iommu=off is different - Last S0i3 Status is Success, 
residency is real, and the wake arrives on IRQ 9 (the ACPI SCI).

That leaves the comparison as, all with 24 CPUs online and no other changes:

   amd_iommu=off    enters s0i3, resumes normally, 2.07s hardware sleep, 
wake on IRQ 9
   IOMMU enabled    never wakes, forced power off required

and from the earlier round, still with the IOMMU enabled and verified 
applied:

   intremap=off             no wake
   iommu=pt                 no wake
   amd_iommu_intr=legacy    no wake

Combined with the pm_test results from the previous mail - freezer, 
devices and platform all pass with the IOMMU enabled - the software 
suspend path is clean and the failure is confined to entering or exiting 
hardware s0i3, but only when the IOMMU is enabled and more than 16 CPUs 
are up.

attached is the full  amd-s2idle report

[-- Attachment #2: s2idle-iommu-off.txt --]
[-- Type: text/plain, Size: 48568 bytes --]

s2idle report created on 2026-09-23 20:07:36.056483 using amd-s2idle unknown [commit acc8749 (&#34;Discover TTM module in initramfs using dracut or mkinitcpio, not just initramfs-tools&#34;)]


⚓ Prerequisite checks
Measured 2026-09-23 20:07:26.
 💻 AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (family 1a model 24)
 🚦 DMI data was not setup
 🐧 Debian GNU/Linux 12 (bookworm)
 🐧 Kernel 6.18.51
 🔋 Battery BAT0 (SMP 5B11H56412) is operating at 102.35% of design
 ✅ ASPM policy set to &#39;default&#39;
 ✅ GPIO driver `pinctrl_amd` available
 ✅ PMC driver `amd_pmc` loaded (Program 11 Firmware 93.23.0)
 ✅ PCIe hotplug driver `pciehp` loaded
 ✅ USB3 driver `xhci_hcd` bound to 0000:c5:00.4, 0000:c7:00.0, 0000:c7:00.3, 0000:c7:00.4
 ✅ USB4 driver `thunderbolt` bound to 0000:c7:00.5, 0000:c7:00.6
 ✅ System is configured for s2idle
 ✅ GPU driver `amdgpu` bound to 0000:c5:00.0
 ✅ PC6 and CC6 enabled
 ✅ SMT enabled
 ✅ IOMMU disabled
 ✅ ACPI FADT supports Low-power S0 idle
 🚦 Logs are provided via dmesg, timestamps may not be accurate over multiple cycles
 ✅ LPS0 _DSM enabled
 ✅ WLAN driver `mt7925e` bound to 0000:c2:00.0

Cycle Data
╒═════════╤════════╕
│   Cycle │ data   │
╞═════════╪════════╡
│       0 │        │
╘═════════╧════════╛

🦟 Debug Data
VCE feature version: 0, firmware version: 0x00000000
UVD feature version: 0, firmware version: 0x00000000
MC feature version: 0, firmware version: 0x00000000
ME feature version: 35, firmware version: 0x0000001d
PFP feature version: 35, firmware version: 0x00000029
CE feature version: 0, firmware version: 0x00000000
RLC feature version: 1, firmware version: 0x11510542
RLC SRLC feature version: 0, firmware version: 0x00000000
RLC SRLG feature version: 0, firmware version: 0x00000000
RLC SRLS feature version: 0, firmware version: 0x00000000
RLCP feature version: 1, firmware version: 0x11510341
RLCV feature version: 0, firmware version: 0x00000000
MEC feature version: 35, firmware version: 0x0000001d
IMU feature version: 0, firmware version: 0x0b332000
SOS feature version: 0, firmware version: 0x00000000
ASD feature version: 553648364, firmware version: 0x210000ec
TA XGMI feature version: 0x00000000, firmware version: 0x00000000
TA RAS feature version: 0x00000000, firmware version: 0x00000000
TA HDCP feature version: 0x00000000, firmware version: 0x17000043
TA DTM feature version: 0x00000000, firmware version: 0x12000018
TA RAP feature version: 0x00000000, firmware version: 0x00000000
TA SECUREDISPLAY feature version: 0x00000000, firmware version: 0x00000000
SMC feature version: 0, program: 11, firmware version: 0x0b5d1700 (93.23.0)
SDMA0 feature version: 60, firmware version: 0x0000000b
VCN feature version: 0, firmware version: 0x09117009
DMCU feature version: 0, firmware version: 0x00000000
DMCUB feature version: 0, firmware version: 0x09001b00
TOC feature version: 0, firmware version: 0x0000000b
MES_KIQ feature version: 6, firmware version: 0x0000006d
MES feature version: 1, firmware version: 0x00000074
VPE feature version: 60, firmware version: 0x00000036
VBIOS version: 113-STRIXEMU-001
PCI Slot | Vendor | Class | ID | ACPI path
│ 0000:00:00.0 |  |  | 1022:1507 | 
│ 0000:00:00.2 |  |  | 1022:1508 | 
│ 0000:00:01.0 |  |  | 1022:1509 | 
│ 0000:00:01.1 |  |  | 1022:150a | \_SB_.PCI0.GPP0
│ 0000:00:01.2 |  |  | 1022:150a | \_SB_.PCI0.GPP1
│ 0000:00:02.0 |  |  | 1022:1509 | 
│ 0000:00:02.1 |  |  | 1022:150b | \_SB_.PCI0.GPP3
├─ 0000:c1:00.0 |  |  | 1c5c:1959 | \_SB_.PCI0.GPP3.NVME
│ 0000:00:02.3 |  |  | 1022:150b | \_SB_.PCI0.GPP5
├─ 0000:c2:00.0 |  |  | 14c3:7925 | \_SB_.PCI0.GPP5.WLAN
│ 0000:00:02.4 |  |  | 1022:150b | \_SB_.PCI0.GPP6
├─ 0000:c3:00.0 |  |  | 10ec:8168 | \_SB_.PCI0.GPP6.RTL8
│ 0000:00:02.5 |  |  | 1022:150b | \_SB_.PCI0.GPP7
├─ 0000:c4:00.0 |  |  | 1eac:1007 | \_SB_.PCI0.GPP7.WWAN
│ 0000:00:03.0 |  |  | 1022:1509 | 
│ 0000:00:08.0 |  |  | 1022:1509 | 
│ 0000:00:08.1 |  |  | 1022:150c | \_SB_.PCI0.GPPA
├─ 0000:c5:00.0 |  |  | 1002:150e | \_SB_.PCI0.GPPA.VGA_
├─ 0000:c5:00.1 |  |  | 1002:1640 | \_SB_.PCI0.GPPA.HDAU
├─ 0000:c5:00.2 |  |  | 1022:17e0 | \_SB_.PCI0.GPPA.PSP_
├─ 0000:c5:00.4 |  |  | 1022:151e | \_SB_.PCI0.GPPA.XHC1
├─ 0000:c5:00.5 |  |  | 1022:15e2 | \_SB_.PCI0.GPPA.ACP_
├─ 0000:c5:00.6 |  |  | 1022:15e3 | \_SB_.PCI0.GPPA.AZAL
│ 0000:00:08.2 |  |  | 1022:150c | \_SB_.PCI0.GPPB
├─ 0000:c6:00.0 |  |  | 1022:150d | 
├─ 0000:c6:00.1 |  |  | 1022:17f0 | \_SB_.PCI0.GPPB.IPU_
│ 0000:00:08.3 |  |  | 1022:150c | \_SB_.PCI0.GPPC
├─ 0000:c7:00.0 |  |  | 1022:151f | \_SB_.PCI0.GPPC.XHC0
├─ 0000:c7:00.3 |  |  | 1022:151a | \_SB_.PCI0.GPPC.XHC3
├─ 0000:c7:00.4 |  |  | 1022:151b | \_SB_.PCI0.GPPC.XHC4
├─ 0000:c7:00.5 |  |  | 1022:151c | \_SB_.PCI0.GPPC.NHI0
├─ 0000:c7:00.6 |  |  | 1022:151d | \_SB_.PCI0.GPPC.NHI1
│ 0000:00:14.0 |  |  | 1022:790b | \_SB_.PCI0.SMBS
│ 0000:00:14.3 |  |  | 1022:790e | \_SB_.PCI0.LPC0
│ 0000:00:18.0 |  |  | 1022:16f8 | 
│ 0000:00:18.1 |  |  | 1022:16f9 | 
│ 0000:00:18.2 |  |  | 1022:16fa | 
│ 0000:00:18.3 |  |  | 1022:16fb | 
│ 0000:00:18.4 |  |  | 1022:16fc | 
│ 0000:00:18.5 |  |  | 1022:16fd | 
│ 0000:00:18.6 |  |  | 1022:16fe | 
└─0000:00:18.7 |  |  | 1022:16ff |
EDID for /sys/devices/pci0000:00/0000:00:08.1/0000:c5:00.0/drm/card0/card0-eDP-1/edid:
│ Block 0, Base EDID:
│ EDID Structure Version &amp; Revision: 1.4
│ Vendor &amp; Product Identification:
│ Manufacturer: LEN
│ Model: 16823
│ Made in: 2024
│ Basic Display Parameters &amp; Features:
│ Digital display
│ Bits per primary color channel: 8
│ DisplayPort interface
│ Maximum image size: 34 cm x 22 cm
│ Gamma: 2.20
│ DPMS levels: Off
│ Supported color formats: RGB 4:4:4
│ First detailed timing includes the native pixel format and preferred refresh rate
│ Display supports continuous frequencies
│ Color Characteristics:
│ Red  : 0.6416, 0.3378
│ Green: 0.3125, 0.6123
│ Blue : 0.1455, 0.0488
│ White: 0.3183, 0.3398
│ Established Timings I &amp; II: none
│ Standard Timings: none
│ Detailed Timing Descriptors:
│ DTD 1:  1920x1200   60.002801 Hz  16:10    74.163 kHz    154.260000 MHz (344 mm x 215 mm)
│ Hfront   48 Hsync  32 Hback   80 Hpol N
│ Vfront   10 Vsync   6 Vback   20 Vpol N
│ Display Range Limits:
│ Monitor ranges (Range Limits Only): 40-60 Hz V, 75-75 kHz H, max dotclock 160 MHz
│ Display Product Name: &#39;N160JCA-GT1&#39;
│ Checksum: 0x5d
│ ----------------
└─ EDID conformity: PASS
ACPI C-state information
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/s2idle/time: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/s2idle/usage: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/disable: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/above: 2374
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/time: 211949395
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/rejected: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/power: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/residency: 700
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/latency: 350
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/usage: 9405
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/desc: ACPI IOPORT 0x415
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/below: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/default_status: enabled
│ /sys/bus/cpu/devices/cpu0/cpuidle/state3/name: C3
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/disable: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/above: 373
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/time: 1199704
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/rejected: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/power: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/residency: 2
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/latency: 1
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/usage: 4225
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/desc: ACPI FFH MWAIT 0x0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/below: 1473
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/default_status: enabled
│ /sys/bus/cpu/devices/cpu0/cpuidle/state1/name: C1
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/s2idle/time: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/s2idle/usage: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/disable: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/above: 475
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/time: 889083
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/rejected: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/power: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/residency: 36
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/latency: 18
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/usage: 3449
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/desc: ACPI IOPORT 0x414
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/below: 146
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/default_status: enabled
│ /sys/bus/cpu/devices/cpu0/cpuidle/state2/name: C2
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/disable: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/above: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/time: 623
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/rejected: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/power: 4294967295
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/residency: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/latency: 0
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/usage: 65
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/desc: CPUIDLE CORE POLL IDLE
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/below: 35
│ /sys/bus/cpu/devices/cpu0/cpuidle/state0/default_status: enabled
└─/sys/bus/cpu/devices/cpu0/cpuidle/state0/name: POLL
I2C HID devices:
│ &#34;ELAN0688:00 04F3:320B Mouse&#34; [ELAN0688] : \_SB_.I2CB.TPD0
└─&#34;ELAN0688:00 04F3:320B Touchpad&#34; [ELAN0688] : \_SB_.I2CB.TPD0
Windows GPIO 0 debounce: enabled
gpio	  int|active|trigger|S0i3| S3|S4/S5| Z|wake|pull|  orient|       debounce|reg
#0	   😛|     ↑|   edge|  ⏰| ⏰|   ⏰|⏰|    |    |input  ↑|↑ (🕑 003660us)|0x805f85f
#8	   😛|     ↓|  level|    |   |     |⏰|    |  ↑ |input  ↑|               |0x8151b00
#17	   😛|     ↓|   edge|  ⏰| ⏰|     |  |    |  ↑ |input  ↑|               |0x157a00
#18	   😛|     ↓|   edge|  ⏰| ⏰|     |  |    |  ↑ |input  ↑|               |0x157a00
#44	   😷|     ↑|   edge|    |   |     |  |    |    |input  ↓|               |0x800
#52	   😷|     ↑|  level|    |   |   ⏰|  |    |    |input  ↓|               |0x8900
#54	   😛|     ↑|   edge|  ⏰| ⏰|     |  |    |    |input  ↓|               |0x7800
#58	   😛|     ↑|  level|  ⏰| ⏰|     |  |    |    |input  ↓|               |0x7900
#59	   😛|     ↑|  level|  ⏰| ⏰|     |  |    |    |input  ↓|               |0x7900
#61	   😛|     ↑|  level|  ⏰| ⏰|     |  |    |    |input  ↓|               |0x7900
#62	   😛|     ↑|  level|  ⏰| ⏰|     |  |    |    |input  ↓|               |0x7900
#172	   😷|     ↑|  level|    |   |     |  |    |    |input  ↓|               |0x900
CPU core count: 24 max: 24
SMT control: on
USB4 routers found, no need to check DMCUB version
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20200925 (64-bit version)
 * Copyright (c) 2000 - 2020 Intel Corporation
 * 
 * Disassembly of /sys/firmware/acpi/tables/IVRS, Wed Sep 23 20:07:26 2026
 *
 * ACPI Data Table [IVRS]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h 0000   4]                    Signature : &#34;IVRS&#34;    [I/O Virtualization Reporting Structure]
[004h 0004   4]                 Table Length : 000001F6
[008h 0008   1]                     Revision : 02
[009h 0009   1]                     Checksum : 18
[00Ah 0010   6]                       Oem ID : &#34;LENOVO&#34;
[010h 0016   8]                 Oem Table ID : &#34;TP-R2X  &#34;
[018h 0024   4]                 Oem Revision : 00001200
[01Ch 0028   4]              Asl Compiler ID : &#34;PTEC&#34;
[020h 0032   4]        Asl Compiler Revision : 00000002

[024h 0036   4]          Virtualization Info : 00203041
[028h 0040   8]                     Reserved : 0000000000000000

[030h 0048   1]                Subtable Type : 10 [Hardware Definition Block]
[031h 0049   1]                        Flags : B0
[032h 0050   2]                       Length : 0044
[034h 0052   2]                     DeviceId : 0002

[036h 0054   2]            Capability Offset : 0040
[038h 0056   8]                 Base Address : 00000000FD200000
[040h 0064   2]            PCI Segment Group : 0000
[042h 0066   2]          Virtualization Info : 0000
[044h 0068   4]            Feature Reporting : 80048F6E

[048h 0072   1]                   Entry Type : 03
[049h 0073   2]                    Device ID : 0003
[04Bh 0075   1]                 Data Setting : 00

[04Ch 0076   1]                   Entry Type : 04
[04Dh 0077   2]                    Device ID : FFFE
[04Fh 0079   1]                 Data Setting : 00

[050h 0080   1]                   Entry Type : 43
[051h 0081   2]                    Device ID : FF00
[053h 0083   1]                 Data Setting : 00
[054h 0084   1]                     Reserved : 00
[055h 0085   2]        Source Used Device ID : 00A5
[057h 0087   1]                     Reserved : 00

[058h 0088   1]                   Entry Type : 04
[059h 0089   2]                    Device ID : FFFF
[05Bh 0091   1]                 Data Setting : 00

[05Ch 0092   1]                   Entry Type : 48
[05Dh 0093   2]                    Device ID : 0000
[05Fh 0095   1]                 Data Setting : 00
[060h 0096   1]                       Handle : 00
[061h 0097   2]        Source Used Device ID : 00A0
[063h 0099   1]                      Variety : 02

[064h 0100   1]                   Entry Type : 48
[065h 0101   2]                    Device ID : 0000
[067h 0103   1]                 Data Setting : D7
[068h 0104   1]                       Handle : 21
[069h 0105   2]        Source Used Device ID : 00A0
[06Bh 0107   1]                      Variety : 01

[06Ch 0108   1]                   Entry Type : 48
[06Dh 0109   2]                    Device ID : 0000
[06Fh 0111   1]                 Data Setting : 00
[070h 0112   1]                       Handle : 22
[071h 0113   2]        Source Used Device ID : 0001
[073h 0115   1]                      Variety : 01

[074h 0116   1]                Subtable Type : 11 [Hardware Definition Block]
[075h 0117   1]                        Flags : 30
[076h 0118   2]                       Length : 0054
[078h 0120   2]                     DeviceId : 0002

[07Ah 0122   2]            Capability Offset : 0040
[07Ch 0124   8]                 Base Address : 00000000FD200000
[084h 0132   2]            PCI Segment Group : 0000
[086h 0134   2]          Virtualization Info : 0000
[088h 0136   4]                   Attributes : 00048000
[08Ch 0140   8]                    EFR Image : 246577EFA2254AFA
[094h 0148   8]                     Reserved : 0000000000000010

[09Ch 0156   1]                   Entry Type : 03
[09Dh 0157   2]                    Device ID : 0003
[09Fh 0159   1]                 Data Setting : 00

[0A0h 0160   1]                   Entry Type : 04
[0A1h 0161   2]                    Device ID : FFFE
[0A3h 0163   1]                 Data Setting : 00

[0A4h 0164   1]                   Entry Type : 43
[0A5h 0165   2]                    Device ID : FF00
[0A7h 0167   1]                 Data Setting : 00
[0A8h 0168   1]                     Reserved : 00
[0A9h 0169   2]        Source Used Device ID : 00A5
[0ABh 0171   1]                     Reserved : 00

[0ACh 0172   1]                   Entry Type : 04
[0ADh 0173   2]                    Device ID : FFFF
[0AFh 0175   1]                 Data Setting : 00

[0B0h 0176   1]                   Entry Type : 48
[0B1h 0177   2]                    Device ID : 0000
[0B3h 0179   1]                 Data Setting : 00
[0B4h 0180   1]                       Handle : 00
[0B5h 0181   2]        Source Used Device ID : 00A0
[0B7h 0183   1]                      Variety : 02

[0B8h 0184   1]                   Entry Type : 48
[0B9h 0185   2]                    Device ID : 0000
[0BBh 0187   1]                 Data Setting : D7
[0BCh 0188   1]                       Handle : 21
[0BDh 0189   2]        Source Used Device ID : 00A0
[0BFh 0191   1]                      Variety : 01

[0C0h 0192   1]                   Entry Type : 48
[0C1h 0193   2]                    Device ID : 0000
[0C3h 0195   1]                 Data Setting : 00
[0C4h 0196   1]                       Handle : 22
[0C5h 0197   2]        Source Used Device ID : 0001
[0C7h 0199   1]                      Variety : 01

[0C8h 0200   1]                Subtable Type : 21 [Memory Definition Block]
[0C9h 0201   1]                        Flags : 08
[0CAh 0202   2]                       Length : 0020
[0CCh 0204   2]                     DeviceId : C507

[0CEh 0206   2]               Auxiliary Data : 0000
[0D0h 0208   8]                     Reserved : 0000000000000000
[0D8h 0216   8]                Start Address : 000000006B400000
[0E0h 0224   8]                Memory Length : 0000000000020000

[0E8h 0232   1]                Subtable Type : 21 [Memory Definition Block]
[0E9h 0233   1]                        Flags : 08
[0EAh 0234   2]                       Length : 0020
[0ECh 0236   2]                     DeviceId : C100

[0EEh 0238   2]               Auxiliary Data : 0000
[0F0h 0240   8]                     Reserved : 0000000000000000
[0F8h 0248   8]                Start Address : 000000006B1F6000
[100h 0256   8]                Memory Length : 0000000000028000

[108h 0264   1]                Subtable Type : 40 [Unknown Subtable Type]
[109h 0265   1]                        Flags : 30
[10Ah 0266   2]                       Length : 00EE
[10Ch 0268   2]                     DeviceId : 0002

**** Unknown IVRS subtable type 0x40

Raw Table Data: Length 502 (0x1F6)

    0000: 49 56 52 53 F6 01 00 00 02 18 4C 45 4E 4F 56 4F  // IVRS......LENOVO
    0010: 54 50 2D 52 32 58 20 20 00 12 00 00 50 54 45 43  // TP-R2X  ....PTEC
    0020: 02 00 00 00 41 30 20 00 00 00 00 00 00 00 00 00  // ....A0 .........
    0030: 10 B0 44 00 02 00 40 00 00 00 20 FD 00 00 00 00  // ..D...@... .....
    0040: 00 00 00 00 6E 8F 04 80 03 03 00 00 04 FE FF 00  // ....n...........
    0050: 43 00 FF 00 00 A5 00 00 04 FF FF 00 48 00 00 00  // C...........H...
    0060: 00 A0 00 02 48 00 00 D7 21 A0 00 01 48 00 00 00  // ....H...!...H...
    0070: 22 01 00 01 11 30 54 00 02 00 40 00 00 00 20 FD  // &#34;....0T...@... .
    0080: 00 00 00 00 00 00 00 00 00 80 04 00 FA 4A 25 A2  // .............J%.
    0090: EF 77 65 24 10 00 00 00 00 00 00 00 03 03 00 00  // .we$............
    00A0: 04 FE FF 00 43 00 FF 00 00 A5 00 00 04 FF FF 00  // ....C...........
    00B0: 48 00 00 00 00 A0 00 02 48 00 00 D7 21 A0 00 01  // H.......H...!...
    00C0: 48 00 00 00 22 01 00 01 21 08 20 00 07 C5 00 00  // H...&#34;...!. .....
    00D0: 00 00 00 00 00 00 00 00 00 00 40 6B 00 00 00 00  // ..........@k....
    00E0: 00 00 02 00 00 00 00 00 21 08 20 00 00 C1 00 00  // ........!. .....
    00F0: 00 00 00 00 00 00 00 00 00 60 1F 6B 00 00 00 00  // .........`.k....
    0100: 00 80 02 00 00 00 00 00 40 30 EE 00 02 00 40 00  // ........@0....@.
    0110: 00 00 20 FD 00 00 00 00 00 00 00 00 00 80 04 00  // .. .............
    0120: FA 4A 25 A2 EF 77 65 24 10 00 00 00 00 00 00 00  // .J%..we$........
    0130: 03 03 00 00 04 FE FF 00 43 00 FF 00 00 A5 00 00  // ........C.......
    0140: 04 FF FF 00 48 00 00 00 00 A0 00 02 48 00 00 D7  // ....H.......H...
    0150: 21 A0 00 01 48 00 00 00 22 01 00 01 F0 A5 00 40  // !...H...&#34;......@
    0160: 41 4D 44 49 30 30 32 30 00 00 00 00 00 00 00 00  // AMDI0020........
    0170: 02 04 49 44 30 30 F0 A5 00 40 41 4D 44 49 30 30  // ..ID00...@AMDI00
    0180: 32 30 00 00 00 00 00 00 00 00 02 04 49 44 30 31  // 20..........ID01
    0190: F0 A5 00 40 41 4D 44 49 30 30 32 30 00 00 00 00  // ...@AMDI0020....
    01A0: 00 00 00 00 02 04 49 44 30 32 F0 99 00 40 41 4D  // ......ID02...@AM
    01B0: 44 49 30 30 32 30 00 00 00 00 00 00 00 00 02 04  // DI0020..........
    01C0: 49 44 30 33 F0 60 00 40 4D 53 46 54 30 32 30 31  // ID03.`.@MSFT0201
    01D0: 00 00 00 00 00 00 00 00 01 02 01 00 F0 99 00 40  // ...............@
    01E0: 41 4D 44 49 30 30 32 30 00 00 00 00 00 00 00 00  // AMDI0020........
    01F0: 02 04 49 44 30 34                                // ..ID04
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20200925 (64-bit version)
 * Copyright (c) 2000 - 2020 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of /sys/firmware/acpi/tables/SSDT22, Wed Sep 23 20:07:26 2026
 *
 * Original Table Header:
 *     Signature        &#34;SSDT&#34;
 *     Length           0x00000C26 (3110)
 *     Revision         0x02
 *     Checksum         0x3F
 *     OEM ID           &#34;LENOVO&#34;
 *     OEM Table ID     &#34;CPMGPIO0&#34;
 *     OEM Revision     0x00000001 (1)
 *     Compiler ID      &#34;INTL&#34;
 *     Compiler Version 0x20210930 (539035952)
 */
DefinitionBlock (&#34;&#34;, &#34;SSDT&#34;, 2, &#34;LENOVO&#34;, &#34;CPMGPIO0&#34;, 0x00000001)
{
    External (_SB_.BTNS, DeviceObj)
    External (_SB_.CMBS, IntObj)
    External (_SB_.GPIO, DeviceObj)
    External (_SB_.PCI0.GPP4, DeviceObj)
    External (_SB_.PCI0.GPP4.SDCR, DeviceObj)
    External (_SB_.PCI0.GPP5, DeviceObj)
    External (_SB_.PCI0.GPP5.WLAN.WLN0, IntObj)
    External (_SB_.PCI0.GPP6, DeviceObj)
    External (_SB_.PCI0.GPP7, DeviceObj)
    External (_SB_.PCI0.GPP7.WWAN.WAN0, IntObj)
    External (_SB_.PCI0.GPP9, DeviceObj)
    External (_SB_.PCI0.GPPA.ACP_, DeviceObj)
    External (_SB_.PCI0.GPPA.AZAL, DeviceObj)
    External (_SB_.PCI0.GPPA.MP2C, DeviceObj)
    External (_SB_.PCI0.GPPA.XHC1, DeviceObj)
    External (_SB_.PCI0.GPPC.XHC0, DeviceObj)
    External (_SB_.PCI0.LPC0.EC0_.HWAK, FieldUnitObj)
    External (_SB_.PWRB, DeviceObj)
    External (M000, MethodObj)    // 1 Arguments
    External (M037, DeviceObj)
    External (M046, IntObj)
    External (M047, IntObj)
    External (M050, DeviceObj)
    External (M051, DeviceObj)
    External (M052, DeviceObj)
    External (M053, DeviceObj)
    External (M054, DeviceObj)
    External (M055, DeviceObj)
    External (M056, DeviceObj)
    External (M057, DeviceObj)
    External (M058, DeviceObj)
    External (M059, DeviceObj)
    External (M062, DeviceObj)
    External (M068, DeviceObj)
    External (M069, DeviceObj)
    External (M070, DeviceObj)
    External (M071, DeviceObj)
    External (M072, DeviceObj)
    External (M074, DeviceObj)
    External (M075, DeviceObj)
    External (M076, DeviceObj)
    External (M077, DeviceObj)
    External (M078, DeviceObj)
    External (M079, DeviceObj)
    External (M080, DeviceObj)
    External (M081, DeviceObj)
    External (M082, FieldUnitObj)
    External (M083, FieldUnitObj)
    External (M084, FieldUnitObj)
    External (M085, FieldUnitObj)
    External (M086, FieldUnitObj)
    External (M087, FieldUnitObj)
    External (M088, FieldUnitObj)
    External (M089, FieldUnitObj)
    External (M090, FieldUnitObj)
    External (M091, FieldUnitObj)
    External (M092, FieldUnitObj)
    External (M093, FieldUnitObj)
    External (M094, FieldUnitObj)
    External (M095, FieldUnitObj)
    External (M096, FieldUnitObj)
    External (M097, FieldUnitObj)
    External (M098, FieldUnitObj)
    External (M099, FieldUnitObj)
    External (M100, FieldUnitObj)
    External (M101, FieldUnitObj)
    External (M102, FieldUnitObj)
    External (M103, FieldUnitObj)
    External (M104, FieldUnitObj)
    External (M105, FieldUnitObj)
    External (M106, FieldUnitObj)
    External (M107, FieldUnitObj)
    External (M108, FieldUnitObj)
    External (M109, FieldUnitObj)
    External (M110, FieldUnitObj)
    External (M115, BuffObj)
    External (M116, BuffFieldObj)
    External (M117, BuffFieldObj)
    External (M118, BuffFieldObj)
    External (M119, BuffFieldObj)
    External (M120, BuffFieldObj)
    External (M122, FieldUnitObj)
    External (M127, DeviceObj)
    External (M128, FieldUnitObj)
    External (M131, FieldUnitObj)
    External (M132, FieldUnitObj)
    External (M133, FieldUnitObj)
    External (M134, FieldUnitObj)
    External (M135, FieldUnitObj)
    External (M136, FieldUnitObj)
    External (M220, FieldUnitObj)
    External (M221, FieldUnitObj)
    External (M226, FieldUnitObj)
    External (M227, DeviceObj)
    External (M229, FieldUnitObj)
    External (M231, FieldUnitObj)
    External (M233, FieldUnitObj)
    External (M235, FieldUnitObj)
    External (M23A, FieldUnitObj)
    External (M251, FieldUnitObj)
    External (M280, FieldUnitObj)
    External (M290, FieldUnitObj)
    External (M29A, FieldUnitObj)
    External (M310, FieldUnitObj)
    External (M31C, FieldUnitObj)
    External (M320, FieldUnitObj)
    External (M321, FieldUnitObj)
    External (M322, FieldUnitObj)
    External (M323, FieldUnitObj)
    External (M324, FieldUnitObj)
    External (M325, FieldUnitObj)
    External (M326, FieldUnitObj)
    External (M327, FieldUnitObj)
    External (M328, FieldUnitObj)
    External (M329, DeviceObj)
    External (M32A, DeviceObj)
    External (M32B, DeviceObj)
    External (M32C, DeviceObj)
    External (M330, DeviceObj)
    External (M331, FieldUnitObj)
    External (M378, FieldUnitObj)
    External (M379, FieldUnitObj)
    External (M380, FieldUnitObj)
    External (M381, FieldUnitObj)
    External (M382, FieldUnitObj)
    External (M383, FieldUnitObj)
    External (M384, FieldUnitObj)
    External (M385, FieldUnitObj)
    External (M386, FieldUnitObj)
    External (M387, FieldUnitObj)
    External (M388, FieldUnitObj)
    External (M389, FieldUnitObj)
    External (M390, FieldUnitObj)
    External (M391, FieldUnitObj)
    External (M392, FieldUnitObj)
    External (M404, BuffObj)
    External (M408, MutexObj)
    External (M414, FieldUnitObj)
    External (M444, FieldUnitObj)
    External (M449, FieldUnitObj)
    External (M453, FieldUnitObj)
    External (M454, FieldUnitObj)
    External (M455, FieldUnitObj)
    External (M456, FieldUnitObj)
    External (M457, FieldUnitObj)
    External (M460, MethodObj)    // 7 Arguments
    External (M4C0, FieldUnitObj)
    External (M4F0, FieldUnitObj)
    External (M610, FieldUnitObj)
    External (M620, FieldUnitObj)
    External (M631, FieldUnitObj)
    External (M652, FieldUnitObj)

    Scope (\)
    {
        Name (HPDW, 0x55)
        Name (WLD3, 0x01)
        Name (APBM, 0x01)
    }

    Scope (\_SB.GPIO)
    {
        Method (_AEI, 0, NotSerialized)  // _AEI: ACPI Event Interrupts
        {
            Name (BUF0, ResourceTemplate ()
            {
                GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
                    &#34;\\_SB.GPIO&#34;, 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x003D
                    }
                GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
                    &#34;\\_SB.GPIO&#34;, 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x003E
                    }
                GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
                    &#34;\\_SB.GPIO&#34;, 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x003A
                    }
                GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
                    &#34;\\_SB.GPIO&#34;, 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x003B
                    }
                GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
                    &#34;\\_SB.GPIO&#34;, 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0036
                    }
            })
            Name (PBTN, ResourceTemplate ()
            {
                GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullDefault, 0x1388,
                    &#34;\\_SB.GPIO&#34;, 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0000
                    }
            })
            Name (BUF1, ResourceTemplate ()
            {
                GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
                    &#34;\\_SB.GPIO&#34;, 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0012
                    }
            })
            Name (BUF2, ResourceTemplate ()
            {
                GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
                    &#34;\\_SB.GPIO&#34;, 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0011
                    }
            })
            If ((\_SB.PCI0.GPP5.WLAN.WLN0 == One))
            {
                M460 (&#34;  OEM-ASL-D3C ConcatenateRes BUF0 and BUF1\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                ConcatenateResTemplate (BUF0, BUF1, Local0)
            }
            Else
            {
                M460 (&#34;  OEM-ASL-D3H Copy BUF0 to Local0\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                Local0 = BUF0 /* \_SB_.GPIO._AEI.BUF0 */
            }

            Local1 = Local0
            If ((APBM == One))
            {
                ConcatenateResTemplate (Local0, PBTN, Local1)
            }

            If ((\_SB.PCI0.GPP7.WWAN.WAN0 != Zero))
            {
                ConcatenateResTemplate (Local1, BUF2, Local2)
            }
            Else
            {
                Local2 = Local1
            }

            M460 (&#34;  OEM-ASL-\\_SB.GPIO._AEI\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
            Return (Local2)
        }

        Method (_EVT, 1, Serialized)  // _EVT: Event
        {
            M460 (&#34;  OEM-ASL-\\_SB.GPIO._EVT-Start Case %d\n&#34;, ToInteger (Arg0), Zero, Zero, Zero, Zero, Zero)
            Switch (ToInteger (Arg0))
            {
                Case (Zero)
                {
                    Local0 = \_SB.PCI0.LPC0.EC0.HWAK /* External reference */
                    If (((Local0 &amp; 0x04) == 0x04)) {}
                    ElseIf (((Local0 &amp; 0x20) == 0x20)) {}
                    ElseIf (((Local0 &amp; 0x40) == 0x40)) {}
                    Else
                    {
                        M000 (0x3900)
                        M460 (&#34;    Notify (\\_SB.PWRB, 0x80)\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                        Notify (\_SB.PWRB, 0x80) // Status Change
                    }
                }
                Case (0x02)
                {
                    M000 (0x3902)
                }
                Case (0x03)
                {
                    M000 (0x3903)
                }
                Case (0x09)
                {
                    M000 (0x3909)
                }
                Case (0x0B)
                {
                    M000 (0x390B)
                }
                Case (0x11)
                {
                    M000 (0x3911)
                    M460 (&#34;    Notify (\\_SB.PCI0.GPP7, 0x02)\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                    Notify (\_SB.PCI0.GPP7, 0x02) // Device Wake
                }
                Case (0x12)
                {
                    M000 (0x3912)
                    If ((\WLD3 == One))
                    {
                        M460 (&#34;    Notify (\\_SB.PCI0.GPP5, 0x02)\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                        Notify (\_SB.PCI0.GPP5, 0x02) // Device Wake
                    }
                }
                Case (0x18)
                {
                    M000 (0x3918)
                }
                Case (0x36)
                {
                    M000 (0x3936)
                    M460 (&#34;    Notify (\\_SB.PCI0.GPPA.MP2C, 0x02)\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                    Notify (\_SB.PCI0.GPPA.MP2C, 0x02) // Device Wake
                    If ((\HPDW == One))
                    {
                        If ((APBM == One))
                        {
                            Notify (\_SB.PWRB, 0x80) // Status Change
                        }
                    }
                }
                Case (0x3A)
                {
                    M000 (0x393A)
                    M460 (&#34;    Notify (\\_SB.PCI0.GPPC.XHC0, 0x02)\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                    Notify (\_SB.PCI0.GPPC.XHC0, 0x02) // Device Wake
                }
                Case (0x3B)
                {
                    M000 (0x393B)
                    M460 (&#34;    Notify (\\_SB.PCI0.GPPA.XHC1, 0x02)\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                    Notify (\_SB.PCI0.GPPA.XHC1, 0x02) // Device Wake
                }
                Case (0x3D)
                {
                    M000 (0x393D)
                    M460 (&#34;    Notify (\\_SB.PCI0.GPPA.AZAL, 0x02)\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                    Notify (\_SB.PCI0.GPPA.AZAL, 0x02) // Device Wake
                }
                Case (0x3E)
                {
                    M000 (0x393E)
                    M460 (&#34;    Notify (\\_SB.PCI0.GPPA.ACP, 0x02)\n&#34;, Zero, Zero, Zero, Zero, Zero, Zero)
                    Notify (\_SB.PCI0.GPPA.ACP, 0x02) // Device Wake
                }

            }

            M460 (&#34;  OEM-ASL-\\_SB.GPIO._EVT-End Case %d\n&#34;, ToInteger (Arg0), Zero, Zero, Zero, Zero, Zero)
        }
    }
}
ACPI name | ACPI path | Kernel driver
LNXSYSTM:00 | \ | None
LNXSYBUS:00 | \_SB_ | None
ACPI0010:00 | \_SB_.PLTF | None
ACPI0007:00 | \_SB_.PLTF.C000 | processor
ACPI0007:01 | \_SB_.PLTF.C001 | processor
ACPI0007:02 | \_SB_.PLTF.C002 | processor
ACPI0007:03 | \_SB_.PLTF.C003 | processor
ACPI0007:04 | \_SB_.PLTF.C004 | processor
ACPI0007:05 | \_SB_.PLTF.C005 | processor
ACPI0007:06 | \_SB_.PLTF.C006 | processor
ACPI0007:07 | \_SB_.PLTF.C007 | processor
ACPI0007:08 | \_SB_.PLTF.C008 | processor
ACPI0007:09 | \_SB_.PLTF.C009 | processor
ACPI0007:0a | \_SB_.PLTF.C00A | processor
ACPI0007:0b | \_SB_.PLTF.C00B | processor
ACPI0007:0c | \_SB_.PLTF.C00C | processor
ACPI0007:0d | \_SB_.PLTF.C00D | processor
ACPI0007:0e | \_SB_.PLTF.C00E | processor
ACPI0007:0f | \_SB_.PLTF.C00F | processor
ACPI0007:10 | \_SB_.PLTF.C010 | processor
ACPI0007:11 | \_SB_.PLTF.C011 | processor
ACPI0007:12 | \_SB_.PLTF.C012 | processor
ACPI0007:13 | \_SB_.PLTF.C013 | processor
ACPI0007:14 | \_SB_.PLTF.C014 | processor
ACPI0007:15 | \_SB_.PLTF.C015 | processor
ACPI0007:16 | \_SB_.PLTF.C016 | processor
ACPI0007:17 | \_SB_.PLTF.C017 | processor
AMDI000A:00 | \_SB_.PEP_ | amd_pmc
AMDI0010:00 | \_SB_.I2CA | i2c_designware
AMDI0010:01 | \_SB_.I2CB | i2c_designware
ELAN0688:00 | \_SB_.I2CB.TPD0 | i2c_hid_acpi
AMDI0010:02 | \_SB_.I2CC | i2c_designware
AMDI0030:00 | \_SB_.GPIO | amd_gpio
AMDI0052:00 | \_SB_.PPKG | None
AMDI0080:00 | \_SB_.VGBI | None
AMDI0081:00 | \_SB_.CIND | None
AMDI0103:00 | \_SB_.PMF_ | None
DRTM0001:00 | \_SB_.DRTM | None
ELASE550:00 | \_SB_.ELD0 | None
ELASEB08:00 | \_SB_.ELD1 | None
MSFT0101:00 | \_SB_.TPM2 | None
MSFT0201:00 | \_SB_.MHSP | None
PNP0A08:00 | \_SB_.PCI0 | None
LNXPOWER:04 | \_SB_.PCI0.GPP3.P0NV | None
LNXPOWER:05 | \_SB_.PCI0.GPP5.PWSR | None
LNXPOWER:09 | \_SB_.PCI0.GPPA.PWRS | None
PNP0103:00 | \_SB_.PCI0.HPET | None
device:00 | \_SB_.PCI0.GPP0 | pcieport
LNXPOWER:01 | \_SB_.PCI0.GPP0.SWUS.PWRS | None
device:01 | \_SB_.PCI0.GPP0.SWUS | None
device:02 | \_SB_.PCI0.GPP1 | pcieport
LNXPOWER:03 | \_SB_.PCI0.GPP1.SWUS.PWRS | None
device:03 | \_SB_.PCI0.GPP1.SWUS | None
device:04 | \_SB_.PCI0.GPP3 | pcieport
device:05 | \_SB_.PCI0.GPP3.NVME | nvme
device:06 | \_SB_.PCI0.GPP4 | None
device:07 | \_SB_.PCI0.GPP4.SDCR | None
device:08 | \_SB_.PCI0.GPP5 | pcieport
device:09 | \_SB_.PCI0.GPP5.WLAN | mt7925e
LNXPOWER:06 | \_SB_.PCI0.GPP5.WLAN.WRST | None
device:0a | \_SB_.PCI0.GPP6 | pcieport
device:0b | \_SB_.PCI0.GPP6.RTL8 | r8169
device:0c | \_SB_.PCI0.GPP6.RUSB | None
device:0d | \_SB_.PCI0.GPP7 | pcieport
device:0e | \_SB_.PCI0.GPP7.WWAN | mhi-pci-generic
LNXPOWER:08 | \_SB_.PCI0.GPP7.WWAN.MRST | None
device:0f | \_SB_.PCI0.GPP8 | None
device:10 | \_SB_.PCI0.GPP9 | None
device:11 | \_SB_.PCI0.GP10 | None
device:12 | \_SB_.PCI0.GP11 | None
device:13 | \_SB_.PCI0.GP12 | None
device:14 | \_SB_.PCI0.GP13 | None
device:15 | \_SB_.PCI0.GP14 | None
device:16 | \_SB_.PCI0.GPPA | pcieport
LNXPOWER:0a | \_SB_.PCI0.GPPA.VGA_.PWRS | None
LNXPOWER:0c | \_SB_.PCI0.GPPA.AZAL.PWRS | None
LNXPOWER:0d | \_SB_.PCI0.GPPA.HDAU.PWRS | None
LNXVIDEO:00 | \_SB_.PCI0.GPPA.VGA_ | amdgpu
device:17 | \_SB_.PCI0.GPPA.VGA_.LCD_ | None
device:18 | \_SB_.PCI0.GPPA.PSP_ | ccp
device:19 | \_SB_.PCI0.GPPA.ACP_ | snd_acp_pci
device:1a | \_SB_.PCI0.GPPA.ACP_.HDA0 | None
device:1b | \_SB_.PCI0.GPPA.ACP_.PDMC | None
device:1c | \_SB_.PCI0.GPPA.ACP_.I2SC | None
device:1d | \_SB_.PCI0.GPPA.ACP_.BTSC | None
device:1e | \_SB_.PCI0.GPPA.ACP_.SDWC | None
device:1f | \_SB_.PCI0.GPPA.ACP_.SDWS | None
device:20 | \_SB_.PCI0.GPPA.ACP_.USBS | None
device:21 | \_SB_.PCI0.GPPA.AZAL | snd_hda_intel
device:22 | \_SB_.PCI0.GPPA.HDAU | None
device:23 | \_SB_.PCI0.GPPA.XHC1 | xhci_hcd
device:24 | \_SB_.PCI0.GPPA.XHC1.RHUB | usb
device:25 | \_SB_.PCI0.GPPA.XHC1.RHUB.PRT1 | None
device:26 | \_SB_.PCI0.GPPA.XHC1.RHUB.PRT1.WCAM | None
device:27 | \_SB_.PCI0.GPPA.XHC1.RHUB.PRT1.ICAM | None
device:28 | \_SB_.PCI0.GPPA.XHC1.RHUB.PRT2 | None
device:29 | \_SB_.PCI0.GPPA.MP2C | None
device:2a | \_SB_.PCI0.GPPB | pcieport
device:2b | \_SB_.PCI0.GPPB.IPU_ | None
device:2c | \_SB_.PCI0.GPPC | pcieport
LNXPOWER:0f | \_SB_.PCI0.GPPC.XHC0.PWRS | None
LNXPOWER:12 | \_SB_.PCI0.GPPC.XHC3.PWRS | None
LNXPOWER:14 | \_SB_.PCI0.GPPC.NHI0.PWRS | None
device:2d | \_SB_.PCI0.GPPC.XHC0 | xhci_hcd
device:2e | \_SB_.PCI0.GPPC.XHC0.RHUB | usb
LNXPOWER:10 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT3.WWPR | None
device:2f | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT1 | None
device:30 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT2 | None
device:31 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT3 | None
device:32 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT4 | None
device:33 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT5 | None
device:34 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT5.PRT1 | None
LNXPOWER:11 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT5.PRT1.BTRT | None
device:35 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT5.PRT2 | None
device:36 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT6 | None
device:37 | \_SB_.PCI0.GPPC.XHC0.RHUB.PRT7 | None
device:38 | \_SB_.PCI0.GPPC.XHC3 | xhci_hcd
device:39 | \_SB_.PCI0.GPPC.XHC3.RHUB | usb
device:3a | \_SB_.PCI0.GPPC.XHC3.RHUB.PRT1 | None
device:3b | \_SB_.PCI0.GPPC.XHC3.RHUB.PRT2 | None
device:3c | \_SB_.PCI0.GPPC.XHC4 | xhci_hcd
device:3d | \_SB_.PCI0.GPPC.XHC4.RHUB | usb
device:3e | \_SB_.PCI0.GPPC.XHC4.RHUB.PRT1 | None
device:3f | \_SB_.PCI0.GPPC.XHC4.RHUB.PRT2 | None
device:40 | \_SB_.PCI0.GPPC.NHI0 | thunderbolt
device:41 | \_SB_.PCI0.GPPC.NHI1 | thunderbolt
device:42 | \_SB_.PCI0.SMBS | piix4_smbus
device:43 | \_SB_.PCI0.LPC0 | None
LEN0071:00 | \_SB_.PCI0.LPC0.KBD_ | i8042 kbd
PNP0000:00 | \_SB_.PCI0.LPC0.PIC_ | None
PNP0100:00 | \_SB_.PCI0.LPC0.TMR_ | None
PNP0200:00 | \_SB_.PCI0.LPC0.DMAC | None
PNP0800:00 | \_SB_.PCI0.LPC0.SPKR | None
PNP0B00:00 | \_SB_.PCI0.LPC0.RTC_ | rtc_cmos
PNP0C01:00 | \_SB_.PCI0.LPC0.SPIR | system
PNP0C02:01 | \_SB_.PCI0.LPC0.SYSR | system
PNP0C04:00 | \_SB_.PCI0.LPC0.COPR | None
PNP0C09:00 | \_SB_.PCI0.LPC0.EC0_ | None
ACPI0003:00 | \_SB_.PCI0.LPC0.EC0_.AC__ | ac
LEN0100:00 | \_SB_.PCI0.LPC0.EC0_.ITSD | None
LEN0111:00 | \_SB_.PCI0.LPC0.EC0_.LSSD | None
LEN0130:00 | \_SB_.PCI0.LPC0.EC0_.LHKF | None
LEN0140:00 | \_SB_.PCI0.LPC0.EC0_.AICD | None
LEN0268:00 | \_SB_.PCI0.LPC0.EC0_.HKEY | None
PNP0C0A:00 | \_SB_.PCI0.LPC0.EC0_.BAT0 | None
PNP0C02:00 | \_SB_.AMDM | system
PNP0C02:02 | \_SB_.AWR0 | None
PNP0C02:03 | \_SB_.AWR0.ABR0 | None
PNP0C02:04 | \_SB_.AWR0.ABR1 | None
PNP0C02:05 | \_SB_.AWR0.ABR2 | None
PNP0C02:06 | \_SB_.AWR0.ABR3 | None
PNP0C02:07 | \_SB_.AWR0.ABR4 | None
PNP0C02:08 | \_SB_.AWR0.ABR5 | None
PNP0C02:09 | \_SB_.AWR0.ABR6 | None
PNP0C02:0a | \_SB_.AWR0.ABR7 | None
PNP0C02:0b | \_SB_.AWR0.ABR8 | None
PNP0C02:0c | \_SB_.AWR0.ABR9 | None
PNP0C02:0d | \_SB_.AWR0.ABRA | None
PNP0C0B:00 | \_SB_.FAN0 | acpi-fan
PNP0C0C:00 | \_SB_.PWRB | None
PNP0C0D:00 | \_SB_.LID_ | None
PNP0C0E:00 | \_SB_.SLPB | None
PNP0C14:00 | \_SB_.WMI1 | acpi-wmi
PNP0C14:01 | \_SB_.WMI2 | acpi-wmi
PNP0C14:02 | \_SB_.WMI3 | acpi-wmi
PNP0C14:03 | \_SB_.WMI4 | acpi-wmi
PNP0C14:04 | \_SB_.WMI5 | acpi-wmi
PNP0C14:05 | \_SB_.WMI6 | acpi-wmi
PNP0C14:06 | \_SB_.WMI7 | acpi-wmi
PNP0C14:07 | \_SB_.WMI8 | acpi-wmi
USBC000:00 | \_SB_.UBTC | ucsi_acpi
device:44 | \_SB_.UBTC.CR01 | None
device:45 | \_SB_.UBTC.CR02 | None
LNXSYBUS:01 | \_TZ_ | None
LNXTHERM:00 | \_TZ_.THM0 | None
PNP0C14:08 | \AOD_ | acpi-wmi
Device firmware checks unavailable without gobject introspection

🦟 Debug Data
Cycle 0
BAT0 energy level is 53160000 µWh
ACPI Lid (/proc/acpi/button/lid/LID/state): open
/proc/cmdline: ramdisk_size=16384 net.ifnames=0 snd-hda-intel.enable=0,1 amd_iommu=off 3
Wakeup Source|Linux Device|Status
ACPI Battery|PNP0C0A:00|enabled
ACPI Lid Switch|PNP0C0D:00|enabled
ACPI Power Button|PNP0C0C:00|enabled
ACPI Sleep Button|PNP0C0E:00|enabled
AT Translated Set 2 keyboard|serio0|enabled
ELAN0688:00 04F3:320B Mouse|i2c-ELAN0688:00|enabled
Mobile Broadband host interface|mhi0|enabled
PCI 60100|0000:00:14.3|enabled
PCI 60100|0000:00:14.3|enabled
PCI 60400|0000:00:01.1|enabled
PCI 60400|0000:00:01.2|enabled
PCI 60400|0000:00:02.1|enabled
PCI 60400|0000:00:02.3|enabled
PCI 60400|0000:00:02.4|enabled
PCI 60400|0000:00:02.5|enabled
PCI C0330|0000:c5:00.4|enabled
PCI C0330|0000:c7:00.0|enabled
PCI C0330|0000:c7:00.3|enabled
PCI C0330|0000:c7:00.4|enabled
PCI C0340|0000:c7:00.5|enabled
PCI C0340|0000:c7:00.6|enabled
Thunderbolt domain|domain0|enabled
Thunderbolt domain|domain1|enabled
USB4 host controller|0-0|enabled
USB4 host controller|1-0|enabled
|/sys/devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:001/wakeup71|enabled
|/sys/devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:002/wakeup72|enabled

IPS status
│ IPS config: 6
│ Idle optimization: 0
│ Idle workqueue - enabled: 1
│ Idle workqueue - running: 0
│ entry counts: rcg=0 ips1=0 ips2=0
└─exit counts: rcg=0 ips1=0 ips2=0
Thermal zones
└─LNXTHERM:00
  	 temp: 39.0°C
  	 critical trip: 113.0°C
  	 hot trip: 112.9°C
Suspend timer programmed for 0:00:30
Woke up from IRQ 9 (IO-APIC 9-fasteoi acpi)

gpe14 increased from 731 to 1005
ACPI Lid (/proc/acpi/button/lid/LID/state): closed
BAT0 energy level is 53140000 µWh
IPS status
│ IPS config: 6
│ Idle optimization: 1
│ Idle workqueue - enabled: 1
│ Idle workqueue - running: 0
│ entry counts: rcg=0 ips1=1 ips2=1
└─exit counts: rcg=0 ips1=1 ips2=1
Thermal zones
└─LNXTHERM:00
  	 39.0°C -&gt; 25.0°C

Summary
╒════╤═════════════════════╤════════════╤══════════════════╤═════════════════╤═════════════════╤═════════════════╤════════════╤═══════════════════════════╕
│    │ Start Time          │ Duration   │ Hardware Sleep   │ Battery Start   │ Battery Delta   │ Average Power   │ Wake Pin   │ Wake Interrupt            │
╞════╪═════════════════════╪════════════╪══════════════════╪═════════════════╪═════════════════╪═════════════════╪════════════╪═══════════════════════════╡
│  0 │ 2026-09-23 20:07:28 │ 0:00:07    │ 28.57%           │ 59.44%          │ -0.02%          │ -10.29W         │            │ Disabled interrupt (acpi) │
╘════╧═════════════════════╧════════════╧══════════════════╧═════════════════╧═════════════════╧═════════════════╧════════════╧═══════════════════════════╛

Failures reported
╒═════════╤══════════════════════════════════════════╤═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╕
│   Cycle │ Problem                                  │ Explanation                                                                                                                                                                                                                                                           │
╞═════════╪══════════════════════════════════════════╪═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
│       0 │ Userspace wasn&#39;t asleep at least 0:00:30 │ The system was programmed to sleep for 0:00:30, but woke up prematurely after 0 days 00:00:07. This typically happens when the system was woken up from a non-timer based source. If you didn&#39;t intentionally wake it up, then there may be a kernel or firmware bug. │
╘═════════╧══════════════════════════════════════════╧═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╛

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

[Mario Limonciello]

On 9/23/26 13:14, Fourhundred Thecat wrote:
> On 2026-09-23 20:11, Mario Limonciello wrote:
>>
>>
>> On 9/23/26 13:02, Fourhundred Thecat wrote:
>>
>> < snip noisy LLM interactions >
>>
>>> I will boot amd_iommu=off next and send the same counters plus a full 
>>> amd-s2idle report from a cycle that actually resumes, so you can see 
>>> whether that configuration reaches hardware sleep or is simply 
>>> failing to get there in a way that happens to stay recoverable.
>>
>> Please attach it when you have it.  Hopefully something stands out to 
>> me what could be wrong with the IOMMU here.
>>
>> Another useful data point will be whether this can reproduce on 7.3- 
>> rc4 with IOMMU enabled to rule out a backport issue.
> 
> 
> amd_iommu=off with all 24 CPUs online does reach hardware sleep. Full 
> amd-s2idle report attached; the relevant parts:
> 
> /sys/kernel/debug/amd_pmc/smu_fw_info after the cycle:
> 
>    Table Version: 3
>    Hint Count: 1
>    Last S0i3 Status: Success
>    Time (in us) to S0i3: 427925
>    Time (in us) in S0i3: 2066740
>    Time (in us) to resume from S0i3: 255153
> 
> /sys/kernel/debug/amd_pmc/s0ix_stats:
> 
>    S0ix Entry Time: 11245218037
>    S0ix Exit Time: 11337753680
>    Residency Time: 1927825
> 
>    /sys/power/suspend_stats/last_hw_sleep:  2066740
>    /sys/power/suspend_stats/total_hw_sleep: 2066740
>    /sys/power/pm_wakeup_irq: 9
> 
> amd-s2idle summary line:
> 
>    Start Time           Duration  Hardware Sleep  Battery Delta  Average 
> Power  Wake Interrupt
>    2026-09-23 20:07:28  0:00:07   28.57%          -0.02%         -10.29W 
>         Disabled interrupt (acpi)

OK looks good.

> 
> The only failure it reports for the cycle is "Userspace wasn't asleep at 
> least 0:00:30", because I woke the machine by hand after 7 seconds. 
> There is no RTC wakealarm on this machine, so every cycle has to be 
> woken manually. Not a real failure.

Uh, the hardware does support a wakealarm.  You might have disabled it 
in your kernel.

> 
> So this settles the question you raised about nr_cpus=16. You were right 
> that it was never a pass: it showed total_hw_sleep=0 and never reached 
> s0i3. amd_iommu=off is different - Last S0i3 Status is Success, 
> residency is real, and the wake arrives on IRQ 9 (the ACPI SCI).
> 
> That leaves the comparison as, all with 24 CPUs online and no other 
> changes:
> 
>    amd_iommu=off    enters s0i3, resumes normally, 2.07s hardware sleep, 
> wake on IRQ 9
>    IOMMU enabled    never wakes, forced power off required
> 
> and from the earlier round, still with the IOMMU enabled and verified 
> applied:
> 
>    intremap=off             no wake
>    iommu=pt                 no wake
>    amd_iommu_intr=legacy    no wake
> 
> Combined with the pm_test results from the previous mail - freezer, 
> devices and platform all pass with the IOMMU enabled - the software 
> suspend path is clean and the failure is confined to entering or exiting 
> hardware s0i3, but only when the IOMMU is enabled and more than 16 CPUs 
> are up.
> 
> attached is the full  amd-s2idle report

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.

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

[Fourhundred Thecat]

[-- Attachment #1: Type: text/plain, Size: 4768 bytes --]

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

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.

>  🚦 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.

> 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

[-- Attachment #2: dmesg-iommu-off.txt --]
[-- Type: text/plain, Size: 92387 bytes --]

[Wed Sep 23 20:03:52 2026] Linux version 6.18.51 (karel@dev) (gcc (Debian 12.2.0-14+deb12u1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Wed Sep 23 19:45:08 CEST 2026
[Wed Sep 23 20:03:52 2026] Command line: BOOT_IMAGE=/beta/vmlinuz-test initrd=/beta/cryptoboot/initrd.xz ramdisk_size=16384 root=/dev/ram rootfstype=ext4 rw net.ifnames=0 snd-hda-intel.enable=0,1 amd_iommu=off 3
[Wed Sep 23 20:03:52 2026] KERNEL supported cpus:
[Wed Sep 23 20:03:52 2026]   AMD AuthenticAMD
[Wed Sep 23 20:03:52 2026] x86/split lock detection: #DB: warning on user-space bus_locks
[Wed Sep 23 20:03:52 2026] BIOS-provided physical RAM map:
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000000100000-0x0000000009afffff] usable
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000009b00000-0x0000000009dfffff] ACPI NVS
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000009e00000-0x0000000009efffff] usable
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000009f00000-0x0000000009f3bfff] ACPI NVS
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000009f3c000-0x00000000686fdfff] usable
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x00000000686fe000-0x0000000074cfdfff] reserved
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000074cfe000-0x0000000074efdfff] ACPI NVS
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000074efe000-0x0000000074ffdfff] ACPI data
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000074ffe000-0x00000000778c3fff] usable
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x00000000778c4000-0x00000000778f2fff] reserved
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x00000000778f3000-0x0000000077ff6fff] usable
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000077ff7000-0x0000000077ffcfff] reserved
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000077ffd000-0x0000000077ffefff] usable
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000077fff000-0x000000007bffffff] reserved
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x000000007d675000-0x000000007fffffff] reserved
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x00000000fd000000-0x00000000ffffffff] reserved
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x0000000100000000-0x000000103e17ffff] usable
[Wed Sep 23 20:03:52 2026] BIOS-e820: [mem 0x000000103e180000-0x00000010a01fffff] reserved
[Wed Sep 23 20:03:52 2026] NX (Execute Disable) protection: active
[Wed Sep 23 20:03:52 2026] APIC: Static calls initialized
[Wed Sep 23 20:03:52 2026] efi: EFI v2.7 by Lenovo
[Wed Sep 23 20:03:52 2026] efi: ACPI=0x74ffd000 ACPI 2.0=0x74ffd014 SMBIOS=0x6f77b000 SMBIOS 3.0=0x6f76e000 TPMFinalLog=0x74dfc000 MEMATTR=0x64484018 RNG=0x74ffb018 TPMEventLog=0x74fef018 
[Wed Sep 23 20:03:52 2026] random: crng init done
[Wed Sep 23 20:03:52 2026] efi: Remove mem333: MMIO range=[0xfd000000-0xffffffff] (48MB) from e820 map
[Wed Sep 23 20:03:52 2026] e820: remove [mem 0xfd000000-0xffffffff] reserved
[Wed Sep 23 20:03:52 2026] efi: Remove mem335: MMIO range=[0x1080000000-0x10a01fffff] (514MB) from e820 map
[Wed Sep 23 20:03:52 2026] e820: remove [mem 0x1080000000-0x10a01fffff] reserved
[Wed Sep 23 20:03:52 2026] SMBIOS 3.4.0 present.
[Wed Sep 23 20:03:52 2026] DMI: LENOVO 21RXS07D00/21RXS07D00, BIOS R2XET40W (1.20 ) 05/26/2026
[Wed Sep 23 20:03:52 2026] DMI: Memory slots populated: 2/2
[Wed Sep 23 20:03:52 2026] tsc: Fast TSC calibration using PIT
[Wed Sep 23 20:03:52 2026] tsc: Detected 1996.318 MHz processor
[Wed Sep 23 20:03:52 2026] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[Wed Sep 23 20:03:52 2026] e820: remove [mem 0x000a0000-0x000fffff] usable
[Wed Sep 23 20:03:52 2026] last_pfn = 0x103e180 max_arch_pfn = 0x400000000
[Wed Sep 23 20:03:52 2026] MTRR map: 5 entries (1 fixed + 4 variable; max 18), built from 9 variable MTRRs
[Wed Sep 23 20:03:52 2026] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[Wed Sep 23 20:03:52 2026] last_pfn = 0x77fff max_arch_pfn = 0x400000000
[Wed Sep 23 20:03:52 2026] Using GB pages for direct mapping
[Wed Sep 23 20:03:52 2026] Secure boot could not be determined
[Wed Sep 23 20:03:52 2026] RAMDISK: [mem 0x5fb1c000-0x6010dfff]
[Wed Sep 23 20:03:52 2026] ACPI: Early table checksum verification disabled
[Wed Sep 23 20:03:52 2026] ACPI: RSDP 0x0000000074FFD014 000024 (v02 LENOVO)
[Wed Sep 23 20:03:52 2026] ACPI: XSDT 0x0000000074FFC228 000184 (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: FACP 0x000000006B466000 000114 (v06 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: DSDT 0x000000006B44C000 017A94 (v02 LENOVO AMD_EDK2 00000000 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: FACS 0x0000000074DEF000 000040
[Wed Sep 23 20:03:52 2026] ACPI: ECDT 0x000000006F7B3000 000054 (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F7B2000 000083 (v02 LENOVO PID0Ssdt 00000010 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F7B1000 000EA1 (v02 LENOVO ProjSsdt 00000010 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F7B0000 0006DF (v02 LENOVO UsbCTabl 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F780000 007F18 (v02 LENOVO AmdTable 00000002 MSFT 05000000)
[Wed Sep 23 20:03:52 2026] ACPI: APIC 0x000000006F6BF000 00011E (v04 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: MCFG 0x000000006F6BE000 00003C (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F67F000 000314 (v02 LENOVO Tpm2Tabl 00001000 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: POAT 0x000000006F67D000 000055 (v03 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: BATB 0x000000006F668000 00004A (v02 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: HPET 0x000000006B465000 000038 (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: WSMT 0x000000006B464000 000028 (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B224000 007EA6 (v02 LENOVO AMD CPU  00000001 AMD  00000001)
[Wed Sep 23 20:03:52 2026] ACPI: VFCT 0x000000006B21E000 005484 (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: ABLT 0x000000006B1F4000 0002C2 (v00 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: FPDT 0x000000006B1F3000 000034 (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F669000 000D54 (v02 LENOVO OEMACP   00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1F1000 001D32 (v02 LENOVO OEMACP   00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1F0000 000A70 (v02 LENOVO OEMPMF   00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1EE000 001DB7 (v02 LENOVO CPMPMF   00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1ED000 000CA9 (v02 LENOVO CPMDFIG4 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1EA000 002AA6 (v02 LENOVO CDFAAIG2 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1E0000 009A56 (v02 LENOVO CPMCMN   00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: BGRT 0x000000006B1DF000 000038 (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1DC000 0023E0 (v02 LENOVO AOD      00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1DB000 000B95 (v02 LENOVO WLAN     00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1D9000 00123F (v02 LENOVO NVME     00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1D7000 0013E2 (v02 LENOVO GpMsSsdt 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1D5000 0019CB (v02 LENOVO UPEP     00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1D3000 00101C (v02 LENOVO GPP_PME_ 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1C9000 0097D1 (v02 LENOVO INTGPPC_ 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1C4000 004608 (v02 LENOVO INTGPPA_ 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1C3000 000C26 (v02 LENOVO CPMGPIO0 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: UEFI 0x0000000074DEE000 00008A (v01 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1C2000 00010D (v02 LENOVO MHSP     00000004 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: TPM2 0x000000006B1C1000 000050 (v05 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006B1C0000 000051 (v02 LENOVO DRTM     00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: IVRS 0x000000006B1BF000 0001F6 (v02 LENOVO TP-R2X   00001200 PTEC 00000002)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F7AE000 000500 (v02 LENOVO MEMTOOL0 00000002 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F7AD000 0009C5 (v02 LENOVO CPMMSOSC 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F7AC000 00008D (v02 LENOVO CPMMSLPI 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F7AB000 000509 (v02 LENOVO CPMSFAML 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: SSDT 0x000000006F7AA000 000F5C (v02 LENOVO CPMACPV8 00000001 INTL 20210930)
[Wed Sep 23 20:03:52 2026] ACPI: Reserving FACP table memory at [mem 0x6b466000-0x6b466113]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving DSDT table memory at [mem 0x6b44c000-0x6b463a93]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving FACS table memory at [mem 0x74def000-0x74def03f]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving ECDT table memory at [mem 0x6f7b3000-0x6f7b3053]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f7b2000-0x6f7b2082]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f7b1000-0x6f7b1ea0]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f7b0000-0x6f7b06de]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f780000-0x6f787f17]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving APIC table memory at [mem 0x6f6bf000-0x6f6bf11d]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving MCFG table memory at [mem 0x6f6be000-0x6f6be03b]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f67f000-0x6f67f313]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving POAT table memory at [mem 0x6f67d000-0x6f67d054]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving BATB table memory at [mem 0x6f668000-0x6f668049]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving HPET table memory at [mem 0x6b465000-0x6b465037]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving WSMT table memory at [mem 0x6b464000-0x6b464027]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b224000-0x6b22bea5]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving VFCT table memory at [mem 0x6b21e000-0x6b223483]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving ABLT table memory at [mem 0x6b1f4000-0x6b1f42c1]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving FPDT table memory at [mem 0x6b1f3000-0x6b1f3033]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f669000-0x6f669d53]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1f1000-0x6b1f2d31]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1f0000-0x6b1f0a6f]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1ee000-0x6b1efdb6]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1ed000-0x6b1edca8]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1ea000-0x6b1ecaa5]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1e0000-0x6b1e9a55]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving BGRT table memory at [mem 0x6b1df000-0x6b1df037]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1dc000-0x6b1de3df]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1db000-0x6b1dbb94]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1d9000-0x6b1da23e]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1d7000-0x6b1d83e1]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1d5000-0x6b1d69ca]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1d3000-0x6b1d401b]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1c9000-0x6b1d27d0]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1c4000-0x6b1c8607]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1c3000-0x6b1c3c25]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving UEFI table memory at [mem 0x74dee000-0x74dee089]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1c2000-0x6b1c210c]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving TPM2 table memory at [mem 0x6b1c1000-0x6b1c104f]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6b1c0000-0x6b1c0050]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving IVRS table memory at [mem 0x6b1bf000-0x6b1bf1f5]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f7ae000-0x6f7ae4ff]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f7ad000-0x6f7ad9c4]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f7ac000-0x6f7ac08c]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f7ab000-0x6f7ab508]
[Wed Sep 23 20:03:52 2026] ACPI: Reserving SSDT table memory at [mem 0x6f7aa000-0x6f7aaf5b]
[Wed Sep 23 20:03:52 2026] Zone ranges:
[Wed Sep 23 20:03:52 2026]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[Wed Sep 23 20:03:52 2026]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[Wed Sep 23 20:03:52 2026]   Normal   [mem 0x0000000100000000-0x000000103e17ffff]
[Wed Sep 23 20:03:52 2026] Movable zone start for each node
[Wed Sep 23 20:03:52 2026] Early memory node ranges
[Wed Sep 23 20:03:52 2026]   node   0: [mem 0x0000000000001000-0x000000000009efff]
[Wed Sep 23 20:03:52 2026]   node   0: [mem 0x0000000000100000-0x0000000009afffff]
[Wed Sep 23 20:03:52 2026]   node   0: [mem 0x0000000009e00000-0x0000000009efffff]
[Wed Sep 23 20:03:52 2026]   node   0: [mem 0x0000000009f3c000-0x00000000686fdfff]
[Wed Sep 23 20:03:52 2026]   node   0: [mem 0x0000000074ffe000-0x00000000778c3fff]
[Wed Sep 23 20:03:52 2026]   node   0: [mem 0x00000000778f3000-0x0000000077ff6fff]
[Wed Sep 23 20:03:52 2026]   node   0: [mem 0x0000000077ffd000-0x0000000077ffefff]
[Wed Sep 23 20:03:52 2026]   node   0: [mem 0x0000000100000000-0x000000103e17ffff]
[Wed Sep 23 20:03:52 2026] Initmem setup node 0 [mem 0x0000000000001000-0x000000103e17ffff]
[Wed Sep 23 20:03:52 2026] On node 0, zone DMA: 1 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] On node 0, zone DMA: 97 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] On node 0, zone DMA32: 768 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] On node 0, zone DMA32: 60 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] On node 0, zone DMA32: 51456 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] On node 0, zone DMA32: 47 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] On node 0, zone DMA32: 6 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] On node 0, zone Normal: 1 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] On node 0, zone Normal: 7808 pages in unavailable ranges
[Wed Sep 23 20:03:52 2026] ACPI: PM-Timer IO Port: 0x408
[Wed Sep 23 20:03:52 2026] ACPI: LAPIC_NMI (acpi_id[0xff] high level lint[0x1])
[Wed Sep 23 20:03:52 2026] IOAPIC[0]: apic_id 33, version 33, address 0xfec00000, GSI 0-23
[Wed Sep 23 20:03:52 2026] IOAPIC[1]: apic_id 34, version 33, address 0xfd280000, GSI 24-55
[Wed Sep 23 20:03:52 2026] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[Wed Sep 23 20:03:52 2026] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[Wed Sep 23 20:03:52 2026] ACPI: Using ACPI (MADT) for SMP configuration information
[Wed Sep 23 20:03:52 2026] ACPI: HPET id: 0x10228201 base: 0xfed00000
[Wed Sep 23 20:03:52 2026] CPU topo: Max. logical packages:   1
[Wed Sep 23 20:03:52 2026] CPU topo: Max. logical dies:       1
[Wed Sep 23 20:03:52 2026] CPU topo: Max. dies per package:   1
[Wed Sep 23 20:03:52 2026] CPU topo: Max. threads per core:   2
[Wed Sep 23 20:03:52 2026] CPU topo: Num. cores per package:    12
[Wed Sep 23 20:03:52 2026] CPU topo: Num. threads per package:  24
[Wed Sep 23 20:03:52 2026] CPU topo: Allowing 24 present CPUs plus 0 hotplug CPUs
[Wed Sep 23 20:03:52 2026] [mem 0x80000000-0xdfffffff] available for PCI devices
[Wed Sep 23 20:03:52 2026] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[Wed Sep 23 20:03:52 2026] setup_percpu: NR_CPUS:24 nr_cpumask_bits:24 nr_cpu_ids:24 nr_node_ids:1
[Wed Sep 23 20:03:52 2026] percpu: Embedded 48 pages/cpu s164952 r0 d31656 u262144
[Wed Sep 23 20:03:52 2026] pcpu-alloc: s164952 r0 d31656 u262144 alloc=1*2097152
[Wed Sep 23 20:03:52 2026] pcpu-alloc: [0] 00 01 02 03 04 05 06 07 [0] 08 09 10 11 12 13 14 15 
[Wed Sep 23 20:03:52 2026] pcpu-alloc: [0] 16 17 18 19 20 21 22 23 
[Wed Sep 23 20:03:52 2026] Kernel command line: BOOT_IMAGE=/beta/vmlinuz-test initrd=/beta/cryptoboot/initrd.xz ramdisk_size=16384 root=/dev/ram rootfstype=ext4 rw net.ifnames=0 snd-hda-intel.enable=0,1 amd_iommu=off 3
[Wed Sep 23 20:03:52 2026] Unknown kernel command line parameters "3", will be passed to user space.
[Wed Sep 23 20:03:52 2026] printk: log buffer data + meta data: 1048576 + 3670016 = 4718592 bytes
[Wed Sep 23 20:03:52 2026] Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes, linear)
[Wed Sep 23 20:03:52 2026] Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear)
[Wed Sep 23 20:03:52 2026] software IO TLB: area num 32.
[Wed Sep 23 20:03:52 2026] Built 1 zonelists, mobility grouping on.  Total pages: 16422060
[Wed Sep 23 20:03:52 2026] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[Wed Sep 23 20:03:52 2026] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=24, Nodes=1
[Wed Sep 23 20:03:52 2026] rcu: Hierarchical RCU implementation.
[Wed Sep 23 20:03:52 2026] 	Tracing variant of Tasks RCU enabled.
[Wed Sep 23 20:03:52 2026] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[Wed Sep 23 20:03:52 2026] RCU Tasks Trace: Setting shift to 5 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=24.
[Wed Sep 23 20:03:52 2026] NR_IRQS: 4352, nr_irqs: 1160, preallocated irqs: 16
[Wed Sep 23 20:03:52 2026] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[Wed Sep 23 20:03:52 2026] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[Wed Sep 23 20:03:52 2026] Console: colour dummy device 80x25
[Wed Sep 23 20:03:52 2026] printk: legacy console [tty0] enabled
[Wed Sep 23 20:03:52 2026] ACPI: Core revision 20250807
[Wed Sep 23 20:03:52 2026] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns
[Wed Sep 23 20:03:52 2026] APIC: Switch to symmetric I/O mode setup
[Wed Sep 23 20:03:52 2026] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[Wed Sep 23 20:03:52 2026] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x398d30097a2, max_idle_ns: 881590574148 ns
[Wed Sep 23 20:03:52 2026] Calibrating delay loop (skipped), value calculated using timer frequency.. 3992.63 BogoMIPS (lpj=7985272)
[Wed Sep 23 20:03:52 2026] SVM disabled (by BIOS) in MSR_VM_CR
[Wed Sep 23 20:03:52 2026] x86/cpu: User Mode Instruction Prevention (UMIP) activated
[Wed Sep 23 20:03:52 2026] LVT offset 1 assigned for vector 0xf9
[Wed Sep 23 20:03:52 2026] LVT offset 2 assigned for vector 0xf4
[Wed Sep 23 20:03:52 2026] Last level iTLB entries: 4KB 64, 2MB 64, 4MB 32
[Wed Sep 23 20:03:52 2026] Last level dTLB entries: 4KB 128, 2MB 128, 4MB 64, 1GB 0
[Wed Sep 23 20:03:52 2026] process: using mwait in idle threads
[Wed Sep 23 20:03:52 2026] mitigations: Enabled attack vectors: user_kernel, user_user, SMT mitigations: auto
[Wed Sep 23 20:03:52 2026] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
[Wed Sep 23 20:03:52 2026] Spectre V2 : Mitigation: Enhanced / Automatic IBRS
[Wed Sep 23 20:03:52 2026] Spectre V2 : User space: Mitigation: STIBP always-on protection
[Wed Sep 23 20:03:52 2026] Speculative Return Stack Overflow: Vulnerable: Microcode, no safe RET
[Wed Sep 23 20:03:52 2026] VMSCAPE: Vulnerable
[Wed Sep 23 20:03:52 2026] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[Wed Sep 23 20:03:52 2026] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 opmask'
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 Hi256'
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 ZMM_Hi256'
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers'
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x800: 'Control-flow User registers'
[Wed Sep 23 20:03:52 2026] x86/fpu: Supporting XSAVE feature 0x1000: 'Control-flow Kernel registers (KVM only)'
[Wed Sep 23 20:03:52 2026] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[Wed Sep 23 20:03:52 2026] x86/fpu: xstate_offset[5]:  832, xstate_sizes[5]:   64
[Wed Sep 23 20:03:52 2026] x86/fpu: xstate_offset[6]:  896, xstate_sizes[6]:  512
[Wed Sep 23 20:03:52 2026] x86/fpu: xstate_offset[7]: 1408, xstate_sizes[7]: 1024
[Wed Sep 23 20:03:52 2026] x86/fpu: xstate_offset[9]: 2432, xstate_sizes[9]:    8
[Wed Sep 23 20:03:52 2026] x86/fpu: xstate_offset[11]: 2440, xstate_sizes[11]:   16
[Wed Sep 23 20:03:52 2026] x86/fpu: xstate_offset[12]: 2456, xstate_sizes[12]:   24
[Wed Sep 23 20:03:52 2026] x86/fpu: Enabled xstate features 0x1ae7, context size is 2480 bytes, using 'compacted' format.
[Wed Sep 23 20:03:52 2026] Freeing SMP alternatives memory: 44K
[Wed Sep 23 20:03:52 2026] pid_max: default: 32768 minimum: 301
[Wed Sep 23 20:03:52 2026] LSM: initializing lsm=capability,landlock
[Wed Sep 23 20:03:52 2026] landlock: Up and running.
[Wed Sep 23 20:03:52 2026] Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[Wed Sep 23 20:03:52 2026] Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[Wed Sep 23 20:03:52 2026] smpboot: CPU0: AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (family: 0x1a, model: 0x24, stepping: 0x0)
[Wed Sep 23 20:03:52 2026] Performance Events: Fam17h+ 16-deep LBR, core perfctr, AMD PMU driver.
[Wed Sep 23 20:03:52 2026] ... version:                   2
[Wed Sep 23 20:03:52 2026] ... bit width:                 48
[Wed Sep 23 20:03:52 2026] ... generic counters:          6
[Wed Sep 23 20:03:52 2026] ... generic bitmap:            000000000000003f
[Wed Sep 23 20:03:52 2026] ... fixed-purpose counters:    0
[Wed Sep 23 20:03:52 2026] ... fixed-purpose bitmap:      0000000000000000
[Wed Sep 23 20:03:52 2026] ... value mask:                0000ffffffffffff
[Wed Sep 23 20:03:52 2026] ... max period:                00007fffffffffff
[Wed Sep 23 20:03:52 2026] ... global_ctrl mask:          000000000000003f
[Wed Sep 23 20:03:52 2026] signal: max sigframe size: 2976
[Wed Sep 23 20:03:52 2026] rcu: Hierarchical SRCU implementation.
[Wed Sep 23 20:03:52 2026] rcu: 	Max phase no-delay instances is 1000.
[Wed Sep 23 20:03:52 2026] Timer migration: 2 hierarchy levels; 8 children per group; 2 crossnode level
[Wed Sep 23 20:03:52 2026] MCE: In-kernel MCE decoding enabled.
[Wed Sep 23 20:03:52 2026] smp: Bringing up secondary CPUs ...
[Wed Sep 23 20:03:52 2026] smpboot: x86: Booting SMP configuration:
[Wed Sep 23 20:03:52 2026] .... node  #0, CPUs:        #1  #2  #3  #4  #5  #6  #7  #8  #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23
[Wed Sep 23 20:03:52 2026] Spectre V2 : Update user space SMT mitigation: STIBP always-on
[Wed Sep 23 20:03:52 2026] smp: Brought up 1 node, 24 CPUs
[Wed Sep 23 20:03:52 2026] smpboot: Total of 24 processors activated (95823.26 BogoMIPS)
[Wed Sep 23 20:03:52 2026] Memory: 64245636K/65688240K available (21273K kernel code, 5641K rwdata, 9744K rodata, 2060K init, 2440K bss, 1430560K reserved, 0K cma-reserved)
[Wed Sep 23 20:03:52 2026] devtmpfs: initialized
[Wed Sep 23 20:03:52 2026] ACPI: PM: Registering ACPI NVS region [mem 0x09b00000-0x09dfffff] (3145728 bytes)
[Wed Sep 23 20:03:52 2026] ACPI: PM: Registering ACPI NVS region [mem 0x09f00000-0x09f3bfff] (245760 bytes)
[Wed Sep 23 20:03:52 2026] ACPI: PM: Registering ACPI NVS region [mem 0x74cfe000-0x74efdfff] (2097152 bytes)
[Wed Sep 23 20:03:52 2026] posixtimers hash table entries: 16384 (order: 6, 262144 bytes, linear)
[Wed Sep 23 20:03:52 2026] futex hash table entries: 8192 (524288 bytes on 1 NUMA nodes, total 512 KiB, linear).
[Wed Sep 23 20:03:52 2026] pinctrl core: initialized pinctrl subsystem
[Wed Sep 23 20:03:52 2026] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[Wed Sep 23 20:03:52 2026] thermal_sys: Registered thermal governor 'step_wise'
[Wed Sep 23 20:03:52 2026] thermal_sys: Registered thermal governor 'user_space'
[Wed Sep 23 20:03:52 2026] cpuidle: using governor ladder
[Wed Sep 23 20:03:52 2026] cpuidle: using governor menu
[Wed Sep 23 20:03:52 2026] NET: Registered PF_QIPCRTR protocol family
[Wed Sep 23 20:03:52 2026] efi: Freeing EFI boot services memory: 174988K
[Wed Sep 23 20:03:52 2026] PCI: ECAM [mem 0xe0000000-0xefffffff] (base 0xe0000000) for domain 0000 [bus 00-ff]
[Wed Sep 23 20:03:52 2026] PCI: Using configuration type 1 for base access
[Wed Sep 23 20:03:52 2026] ACPI: Added _OSI(Module Device)
[Wed Sep 23 20:03:52 2026] ACPI: Added _OSI(Processor Device)
[Wed Sep 23 20:03:52 2026] ACPI: Added _OSI(Processor Aggregator Device)
[Wed Sep 23 20:03:52 2026] ACPI: 30 ACPI AML tables successfully acquired and loaded
[Wed Sep 23 20:03:52 2026] ACPI: EC: EC started
[Wed Sep 23 20:03:52 2026] ACPI: EC: interrupt blocked
[Wed Sep 23 20:03:52 2026] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
[Wed Sep 23 20:03:52 2026] ACPI: EC: Boot ECDT EC used to handle transactions
[Wed Sep 23 20:03:52 2026] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[Wed Sep 23 20:03:52 2026] ACPI: USB4 _OSC: OS supports USB3+ DisplayPort+ PCIe+ XDomain+
[Wed Sep 23 20:03:52 2026] ACPI: USB4 _OSC: OS controls USB3+ DisplayPort+ PCIe+ XDomain+
[Wed Sep 23 20:03:52 2026] ACPI: Interpreter enabled
[Wed Sep 23 20:03:52 2026] ACPI: PM: (supports S0 S5)
[Wed Sep 23 20:03:52 2026] ACPI: Using IOAPIC for interrupt routing
[Wed Sep 23 20:03:52 2026] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[Wed Sep 23 20:03:52 2026] PCI: Ignoring E820 reservations for host bridge windows
[Wed Sep 23 20:03:52 2026] ACPI: Enabled 3 GPEs in block 00 to 1F
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP0.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP0.SWUS.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP1.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP1.SWUS.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP3.P0NV: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP5.PWSR: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP5.WLAN.WRST: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP7.P0WW: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPP7.WWAN.MRST: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPA.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPA.VGA_.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPA.ACP_.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPA.AZAL.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPA.HDAU.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPA.XHC1.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPC.XHC0.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPC.XHC0.RHUB.PRT3.WWPR: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPC.XHC0.RHUB.PRT5.PRT1.BTRT: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPC.XHC3.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPC.XHC4.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPC.NHI0.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.GPPC.NHI1.PWRS: New power resource
[Wed Sep 23 20:03:52 2026] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[Wed Sep 23 20:03:52 2026] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[Wed Sep 23 20:03:52 2026] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability LTR]
[Wed Sep 23 20:03:52 2026] PCI host bridge to bus 0000:00
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0x80000000-0xdfffffff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfcffffff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0x10a0200000-0x893fffffff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [io  0x1000-0xfeff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [io  0x0d00-0x0fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0xfec00000-0xfec01fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0xfed45000-0xfed811ff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0xfed81900-0xfed81fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0xfedc0000-0xfedc0fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0xfedc6000-0xfedc6fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [mem 0xfee01000-0xffffffff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: root bus resource [bus 00-ff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:00.0: [1022:1507] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:00.2: [1022:1508] type 00 class 0x080600 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.0: [1022:1509] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1: [1022:150a] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1: PCI bridge to [bus 01-60]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1:   bridge window [io  0x7000-0xafff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1:   bridge window [mem 0x98000000-0xafffffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1:   bridge window [mem 0x3800000000-0x57ffffffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2: [1022:150a] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2: PCI bridge to [bus 61-c0]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2:   bridge window [io  0x3000-0x6fff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2:   bridge window [mem 0x80000000-0x97ffffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2:   bridge window [mem 0x1800000000-0x37ffffffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.0: [1022:1509] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.1: [1022:150b] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.1: PCI bridge to [bus c1]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.1:   bridge window [mem 0xb1100000-0xb11fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.1: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.3: [1022:150b] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.3: PCI bridge to [bus c2]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.3:   bridge window [mem 0xb0600000-0xb08fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.3: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4: [1022:150b] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4: PCI bridge to [bus c3]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4:   bridge window [io  0x2000-0x2fff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4:   bridge window [mem 0xb1000000-0xb10fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.5: [1022:150b] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.5: PCI bridge to [bus c4]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.5:   bridge window [mem 0xb0f00000-0xb0ffffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.5: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:03.0: [1022:1509] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.0: [1022:1509] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1: [1022:150c] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1: PCI bridge to [bus c5]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1:   bridge window [io  0x1000-0x1fff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1:   bridge window [mem 0xb0000000-0xb04fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1:   bridge window [mem 0x5800000000-0x58107fffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2: [1022:150c] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2: PCI bridge to [bus c6]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2:   bridge window [mem 0xb0d00000-0xb0efffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2:   bridge window [mem 0x5810800000-0x58108fffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.3: [1022:150c] type 01 class 0x060400 PCIe Root Port
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.3: PCI bridge to [bus c7]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.3:   bridge window [mem 0xb0900000-0xb0cfffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.3: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.3: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:14.0: [1022:790b] type 00 class 0x0c0500 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:14.3: [1022:790e] type 00 class 0x060100 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:18.0: [1022:16f8] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:18.1: [1022:16f9] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:18.2: [1022:16fa] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:18.3: [1022:16fb] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:18.4: [1022:16fc] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:18.5: [1022:16fd] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:18.6: [1022:16fe] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:18.7: [1022:16ff] type 00 class 0x060000 conventional PCI endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1: PCI bridge to [bus 01-60]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2: PCI bridge to [bus 61-c0]
[Wed Sep 23 20:03:52 2026] pci 0000:c1:00.0: [1c5c:1959] type 00 class 0x010802 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c1:00.0: BAR 0 [mem 0xb1100000-0xb1103fff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.1: PCI bridge to [bus c1]
[Wed Sep 23 20:03:52 2026] pci 0000:c2:00.0: [14c3:7925] type 00 class 0x028000 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c2:00.0: BAR 0 [mem 0xb0600000-0xb07fffff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c2:00.0: BAR 2 [mem 0xb0800000-0xb0807fff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c2:00.0: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.3: PCI bridge to [bus c2]
[Wed Sep 23 20:03:52 2026] pci 0000:c3:00.0: [10ec:8168] type 00 class 0x020000 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c3:00.0: BAR 0 [io  0x2000-0x20ff]
[Wed Sep 23 20:03:52 2026] pci 0000:c3:00.0: BAR 2 [mem 0xb1004000-0xb1004fff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c3:00.0: BAR 4 [mem 0xb1000000-0xb1003fff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c3:00.0: supports D1 D2
[Wed Sep 23 20:03:52 2026] pci 0000:c3:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4: PCI bridge to [bus c3]
[Wed Sep 23 20:03:52 2026] pci 0000:c4:00.0: [1eac:1007] type 00 class 0xff0000 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c4:00.0: BAR 0 [mem 0xb0f00000-0xb0f00fff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c4:00.0: BAR 2 [mem 0xb0f01000-0xb0f01fff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c4:00.0: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c4:00.0: 4.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x1 link at 0000:00:02.5 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link)
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.5: PCI bridge to [bus c4]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.0: [1002:150e] type 00 class 0x038000 PCIe Legacy Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.0: BAR 0 [mem 0x5800000000-0x580fffffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.0: BAR 2 [mem 0xb0000000-0xb01fffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.0: BAR 4 [io  0x1000-0x10ff]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.0: BAR 5 [mem 0xb0400000-0xb047ffff]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.0: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.0: PME# supported from D1 D2 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.1: [1002:1640] type 00 class 0x040300 PCIe Legacy Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.1: BAR 0 [mem 0xb04c8000-0xb04cbfff]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.1: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.1: PME# supported from D1 D2 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.2: [1022:17e0] type 00 class 0x108000 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.2: BAR 2 [mem 0xb0300000-0xb03fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.2: BAR 5 [mem 0xb04cc000-0xb04cdfff]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.2: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.4: [1022:151e] type 00 class 0x0c0330 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.4: BAR 0 [mem 0xb0200000-0xb02fffff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.4: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.4: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.5: [1022:15e2] type 00 class 0x048000 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.5: BAR 0 [mem 0xb0480000-0xb04bffff]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.5: BAR 2 [mem 0x5810000000-0x58107fffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.5: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.5: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.6: [1022:15e3] type 00 class 0x040300 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.6: BAR 0 [mem 0xb04c0000-0xb04c7fff]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.6: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.6: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1: PCI bridge to [bus c5]
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.0: [1022:150d] type 00 class 0x130000 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.0: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.1: [1022:17f0] type 00 class 0x118000 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.1: BAR 0 [mem 0xb0d00000-0xb0dfffff]
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.1: BAR 1 [mem 0xb0e00000-0xb0e01fff]
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.1: BAR 2 [mem 0x5810800000-0x581087ffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.1: BAR 4 [mem 0xb0e03000-0xb0e03fff]
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.1: BAR 5 [mem 0xb0e02000-0xb0e02fff]
[Wed Sep 23 20:03:52 2026] pci 0000:c6:00.1: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2: PCI bridge to [bus c6]
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.0: [1022:151f] type 00 class 0x0c0330 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.0: BAR 0 [mem 0xb0900000-0xb09fffff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.0: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.0: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.3: [1022:151a] type 00 class 0x0c0330 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.3: BAR 0 [mem 0xb0a00000-0xb0afffff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.3: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.3: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.4: [1022:151b] type 00 class 0x0c0330 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.4: BAR 0 [mem 0xb0b00000-0xb0bfffff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.4: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.4: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.5: [1022:151c] type 00 class 0x0c0340 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.5: BAR 0 [mem 0xb0c00000-0xb0c7ffff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.5: Max Payload Size set to 128 (was 256, max 256)
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.5: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.5: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.6: [1022:151d] type 00 class 0x0c0340 PCIe Endpoint
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.6: BAR 0 [mem 0xb0c80000-0xb0cfffff 64bit]
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.6: Max Payload Size set to 128 (was 256, max 256)
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.6: enabling Extended Tags
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.6: PME# supported from D0 D3hot D3cold
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.3: PCI bridge to [bus c7]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: on NUMA node 0
[Wed Sep 23 20:03:52 2026] Low-power S0 idle used by default for system suspend
[Wed Sep 23 20:03:52 2026] ACPI: EC: interrupt unblocked
[Wed Sep 23 20:03:52 2026] ACPI: EC: event unblocked
[Wed Sep 23 20:03:52 2026] ACPI: EC: EC_CMD/EC_SC=0x66, EC_DATA=0x62
[Wed Sep 23 20:03:52 2026] ACPI: EC: GPE=0x14
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.LPC0.EC0_: Boot ECDT EC initialization complete
[Wed Sep 23 20:03:52 2026] ACPI: \_SB_.PCI0.LPC0.EC0_: EC: Used to handle transactions and events
[Wed Sep 23 20:03:52 2026] iommu: Default domain type: Translated
[Wed Sep 23 20:03:52 2026] iommu: DMA domain TLB invalidation policy: lazy mode
[Wed Sep 23 20:03:52 2026] SCSI subsystem initialized
[Wed Sep 23 20:03:52 2026] libata version 3.00 loaded.
[Wed Sep 23 20:03:52 2026] ACPI: bus type USB registered
[Wed Sep 23 20:03:52 2026] usbcore: registered new interface driver usbfs
[Wed Sep 23 20:03:52 2026] usbcore: registered new interface driver hub
[Wed Sep 23 20:03:52 2026] usbcore: registered new device driver usb
[Wed Sep 23 20:03:52 2026] mc: Linux media interface: v0.10
[Wed Sep 23 20:03:52 2026] videodev: Linux video capture interface: v2.00
[Wed Sep 23 20:03:52 2026] EDAC MC: Ver: 3.0.0
[Wed Sep 23 20:03:52 2026] efivars: Registered efivars operations
[Wed Sep 23 20:03:52 2026] Advanced Linux Sound Architecture Driver Initialized.
[Wed Sep 23 20:03:52 2026] Bluetooth: Core ver 2.22
[Wed Sep 23 20:03:52 2026] NET: Registered PF_BLUETOOTH protocol family
[Wed Sep 23 20:03:52 2026] Bluetooth: HCI device and connection manager initialized
[Wed Sep 23 20:03:52 2026] Bluetooth: HCI socket layer initialized
[Wed Sep 23 20:03:52 2026] Bluetooth: L2CAP socket layer initialized
[Wed Sep 23 20:03:52 2026] Bluetooth: SCO socket layer initialized
[Wed Sep 23 20:03:52 2026] PCI: Using ACPI for IRQ routing
[Wed Sep 23 20:03:52 2026] PCI: pci_cache_line_size set to 64 bytes
[Wed Sep 23 20:03:52 2026] e820: reserve RAM buffer [mem 0x0009f000-0x0009ffff]
[Wed Sep 23 20:03:52 2026] e820: reserve RAM buffer [mem 0x09b00000-0x0bffffff]
[Wed Sep 23 20:03:52 2026] e820: reserve RAM buffer [mem 0x09f00000-0x0bffffff]
[Wed Sep 23 20:03:52 2026] e820: reserve RAM buffer [mem 0x686fe000-0x6bffffff]
[Wed Sep 23 20:03:52 2026] e820: reserve RAM buffer [mem 0x778c4000-0x77ffffff]
[Wed Sep 23 20:03:52 2026] e820: reserve RAM buffer [mem 0x77ff7000-0x77ffffff]
[Wed Sep 23 20:03:52 2026] e820: reserve RAM buffer [mem 0x77fff000-0x77ffffff]
[Wed Sep 23 20:03:52 2026] e820: reserve RAM buffer [mem 0x103e180000-0x103fffffff]
[Wed Sep 23 20:03:52 2026] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[Wed Sep 23 20:03:52 2026] hpet0: 3 comparators, 32-bit 14.318180 MHz counter
[Wed Sep 23 20:03:52 2026] clocksource: Switched to clocksource tsc-early
[Wed Sep 23 20:03:52 2026] pnp: PnP ACPI init
[Wed Sep 23 20:03:52 2026] system 00:00: [mem 0xe0000000-0xefffffff] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x0400-0x04cf] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x04d0-0x04d1] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x04d6] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x0c00-0x0c01] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x0c14] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x0c50-0x0c52] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x0c6c] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x0c6f] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:01: [io  0x0cd0-0x0cdb] has been reserved
[Wed Sep 23 20:03:52 2026] system 00:02: [mem 0xff000000-0xffffffff] has been reserved
[Wed Sep 23 20:03:52 2026] pnp: PnP ACPI: found 4 devices
[Wed Sep 23 20:03:52 2026] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[Wed Sep 23 20:03:52 2026] NET: Registered PF_INET protocol family
[Wed Sep 23 20:03:52 2026] IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[Wed Sep 23 20:03:52 2026] tcp_listen_portaddr_hash hash table entries: 32768 (order: 7, 524288 bytes, linear)
[Wed Sep 23 20:03:52 2026] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[Wed Sep 23 20:03:52 2026] TCP established hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[Wed Sep 23 20:03:52 2026] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear)
[Wed Sep 23 20:03:52 2026] TCP: Hash tables configured (established 524288 bind 65536)
[Wed Sep 23 20:03:52 2026] UDP hash table entries: 32768 (order: 9, 2097152 bytes, linear)
[Wed Sep 23 20:03:52 2026] UDP-Lite hash table entries: 32768 (order: 9, 2097152 bytes, linear)
[Wed Sep 23 20:03:52 2026] NET: Registered PF_UNIX/PF_LOCAL protocol family
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1: PCI bridge to [bus 01-60]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1:   bridge window [io  0x7000-0xafff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1:   bridge window [mem 0x98000000-0xafffffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.1:   bridge window [mem 0x3800000000-0x57ffffffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2: PCI bridge to [bus 61-c0]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2:   bridge window [io  0x3000-0x6fff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2:   bridge window [mem 0x80000000-0x97ffffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:01.2:   bridge window [mem 0x1800000000-0x37ffffffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.1: PCI bridge to [bus c1]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.1:   bridge window [mem 0xb1100000-0xb11fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.3: PCI bridge to [bus c2]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.3:   bridge window [mem 0xb0600000-0xb08fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4: PCI bridge to [bus c3]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4:   bridge window [io  0x2000-0x2fff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.4:   bridge window [mem 0xb1000000-0xb10fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.5: PCI bridge to [bus c4]
[Wed Sep 23 20:03:52 2026] pci 0000:00:02.5:   bridge window [mem 0xb0f00000-0xb0ffffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1: PCI bridge to [bus c5]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1:   bridge window [io  0x1000-0x1fff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1:   bridge window [mem 0xb0000000-0xb04fffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.1:   bridge window [mem 0x5800000000-0x58107fffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2: PCI bridge to [bus c6]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2:   bridge window [mem 0xb0d00000-0xb0efffff]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.2:   bridge window [mem 0x5810800000-0x58108fffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.3: PCI bridge to [bus c7]
[Wed Sep 23 20:03:52 2026] pci 0000:00:08.3:   bridge window [mem 0xb0900000-0xb0cfffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 4 [mem 0x80000000-0xdfffffff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 5 [mem 0xf0000000-0xfcffffff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 6 [mem 0x10a0200000-0x893fffffff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 7 [io  0x1000-0xfeff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 8 [io  0x0000-0x0cf7 window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 9 [io  0x0d00-0x0fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 10 [mem 0xfec00000-0xfec01fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 11 [mem 0xfed45000-0xfed811ff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 12 [mem 0xfed81900-0xfed81fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 13 [mem 0xfedc0000-0xfedc0fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 14 [mem 0xfedc6000-0xfedc6fff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:00: resource 15 [mem 0xfee01000-0xffffffff window]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:01: resource 0 [io  0x7000-0xafff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:01: resource 1 [mem 0x98000000-0xafffffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:01: resource 2 [mem 0x3800000000-0x57ffffffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:61: resource 0 [io  0x3000-0x6fff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:61: resource 1 [mem 0x80000000-0x97ffffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:61: resource 2 [mem 0x1800000000-0x37ffffffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c1: resource 1 [mem 0xb1100000-0xb11fffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c2: resource 1 [mem 0xb0600000-0xb08fffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c3: resource 0 [io  0x2000-0x2fff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c3: resource 1 [mem 0xb1000000-0xb10fffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c4: resource 1 [mem 0xb0f00000-0xb0ffffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c5: resource 0 [io  0x1000-0x1fff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c5: resource 1 [mem 0xb0000000-0xb04fffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c5: resource 2 [mem 0x5800000000-0x58107fffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c6: resource 1 [mem 0xb0d00000-0xb0efffff]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c6: resource 2 [mem 0x5810800000-0x58108fffff 64bit pref]
[Wed Sep 23 20:03:52 2026] pci_bus 0000:c7: resource 1 [mem 0xb0900000-0xb0cfffff]
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.1: D0 power state depends on 0000:c5:00.0
[Wed Sep 23 20:03:52 2026] pci 0000:c5:00.4: enabling device (0000 -> 0002)
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.3: enabling device (0000 -> 0002)
[Wed Sep 23 20:03:52 2026] pci 0000:c7:00.4: enabling device (0000 -> 0002)
[Wed Sep 23 20:03:52 2026] PCI: CLS 0 bytes, default 64
[Wed Sep 23 20:03:52 2026] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[Wed Sep 23 20:03:52 2026] software IO TLB: mapped [mem 0x0000000057700000-0x000000005b700000] (64MB)
[Wed Sep 23 20:03:52 2026] ACPI: bus type thunderbolt registered
[Wed Sep 23 20:03:52 2026] Trying to unpack rootfs image as initramfs...
[Wed Sep 23 20:03:52 2026] rootfs image is not initramfs (no cpio magic); looks like an initrd
[Wed Sep 23 20:03:52 2026] Freeing initrd memory: 6088K
[Wed Sep 23 20:03:52 2026] RAPL PMU: API unit is 2^-32 Joules, 2 fixed counters, 163840 ms ovfl timer
[Wed Sep 23 20:03:52 2026] RAPL PMU: hw unit of domain package 2^-16 Joules
[Wed Sep 23 20:03:52 2026] RAPL PMU: hw unit of domain core 2^-16 Joules
[Wed Sep 23 20:03:52 2026] LVT offset 0 assigned for vector 0x400
[Wed Sep 23 20:03:52 2026] perf: AMD IBS detected (0x00081bff)
[Wed Sep 23 20:03:52 2026] amd_uncore: 8 amd_df counters detected
[Wed Sep 23 20:03:52 2026] amd_uncore: 6 amd_l3 counters detected
[Wed Sep 23 20:03:52 2026] amd_uncore: 4 amd_umc_0 counters detected
[Wed Sep 23 20:03:52 2026] amd_uncore: 4 amd_umc_1 counters detected
[Wed Sep 23 20:03:52 2026] amd_uncore: 4 amd_umc_2 counters detected
[Wed Sep 23 20:03:52 2026] amd_uncore: 4 amd_umc_3 counters detected
[Wed Sep 23 20:03:52 2026] Initialise system trusted keyrings
[Wed Sep 23 20:03:52 2026] workingset: timestamp_bits=62 max_order=24 bucket_order=0
[Wed Sep 23 20:03:52 2026] fuse: init (API version 7.45)
[Wed Sep 23 20:03:52 2026] cryptd: max_cpu_qlen set to 1000
[Wed Sep 23 20:03:52 2026] Key type asymmetric registered
[Wed Sep 23 20:03:52 2026] Asymmetric key parser 'x509' registered
[Wed Sep 23 20:03:52 2026] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[Wed Sep 23 20:03:52 2026] io scheduler mq-deadline registered
[Wed Sep 23 20:03:52 2026] io scheduler kyber registered
[Wed Sep 23 20:03:52 2026] mhi-pci-generic 0000:c4:00.0: MHI PCI device found: quectel-rm5xx
[Wed Sep 23 20:03:52 2026] mhi-pci-generic 0000:c4:00.0: enabling device (0000 -> 0002)
[Wed Sep 23 20:03:52 2026] mhi-pci-generic 0000:c4:00.0: using shared MSI
[Wed Sep 23 20:03:52 2026] mhi mhi0: Requested to power ON
[Wed Sep 23 20:03:52 2026] mhi mhi0: Power on setup success
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:01.1: PME: Signaling with IRQ 69
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:01.1: pciehp: Slot #0 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:01.2: PME: Signaling with IRQ 70
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:01.2: pciehp: Slot #0 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:02.1: PME: Signaling with IRQ 71
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:02.3: PME: Signaling with IRQ 72
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:02.4: PME: Signaling with IRQ 73
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:02.5: PME: Signaling with IRQ 74
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:08.1: PME: Signaling with IRQ 75
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:08.2: PME: Signaling with IRQ 76
[Wed Sep 23 20:03:52 2026] pcieport 0000:00:08.3: PME: Signaling with IRQ 77
[Wed Sep 23 20:03:52 2026] ACPI: AC: AC Adapter [AC] (off-line)
[Wed Sep 23 20:03:52 2026] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[Wed Sep 23 20:03:52 2026] ACPI: button: Power Button [PWRB]
[Wed Sep 23 20:03:52 2026] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input1
[Wed Sep 23 20:03:52 2026] ACPI: button: Lid Switch [LID]
[Wed Sep 23 20:03:52 2026] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input2
[Wed Sep 23 20:03:52 2026] ACPI: button: Sleep Button [SLPB]
[Wed Sep 23 20:03:52 2026] ACPI: video: Video Device [VGA] (multi-head: yes  rom: no  post: no)
[Wed Sep 23 20:03:52 2026] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:16/LNXVIDEO:00/input/input3
[Wed Sep 23 20:03:52 2026] Monitor-Mwait will be used to enter C-1 state
[Wed Sep 23 20:03:52 2026] Estimated ratio of average max frequency by base frequency (times 1024): 1832
[Wed Sep 23 20:03:52 2026] thermal LNXTHERM:00: registered as thermal_zone0
[Wed Sep 23 20:03:52 2026] ACPI: thermal: Thermal Zone [THM0] (44 C)
[Wed Sep 23 20:03:52 2026] Non-volatile memory driver v1.3
[Wed Sep 23 20:03:52 2026] ACPI: battery: Slot [BAT0] (battery present)
[Wed Sep 23 20:03:52 2026] tpm_crb MSFT0101:00: Disabling hwrng
[Wed Sep 23 20:03:52 2026] ACPI: bus type drm_connector registered
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: enabling device (0006 -> 0007)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: initializing kernel modesetting (IP DISCOVERY 0x1002:0x150E 0x17AA:0x512F 0xD1).
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: register mmio base: 0xB0400000
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: register mmio size: 524288
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 0 <common_v1_0_0> (soc21_common)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 1 <gmc_v11_0_0> (gmc_v11_0)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 2 <ih_v6_0_0> (ih_v6_1)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 3 <psp_v13_0_0> (psp)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 4 <smu_v14_0_0> (smu)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 5 <dce_v1_0_0> (dm)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 6 <gfx_v11_0_0> (gfx_v11_0)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 7 <sdma_v6_0_0> (sdma_v6_0)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 8 <vcn_v4_0_5> (vcn_v4_0_5)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 9 <jpeg_v4_0_5> (jpeg_v4_0_5)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 10 <mes_v11_0_0> (mes_v11_0)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: detected ip block number 11 <vpe_v6_1_0> (vpe_v6_1)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: Fetched VBIOS from VFCT
[Wed Sep 23 20:03:52 2026] amdgpu: ATOM BIOS: 113-STRIXEMU-001
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: VPE: collaborate mode false
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: Trusted Memory Zone (TMZ) feature disabled as experimental (default)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: VRAM: 1024M 0x0000008000000000 - 0x000000803FFFFFFF (1024M used)
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: GART: 512M 0x00007FFF00000000 - 0x00007FFF1FFFFFFF
[Wed Sep 23 20:03:52 2026] [drm] Detected VRAM RAM=1024M, BAR=1024M
[Wed Sep 23 20:03:52 2026] [drm] RAM width 128bits DDR5
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: amdgpu: 1024M of VRAM memory ready
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: amdgpu: 31464M of GTT memory ready.
[Wed Sep 23 20:03:52 2026] [drm] GART: num cpu pages 131072, num gpu pages 131072
[Wed Sep 23 20:03:52 2026] [drm] PCIE GART of 512M enabled (table at 0x0000008000900000).
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] Loading DMUB firmware via PSP: version=0x09001B00
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: [VCN instance 0] Found VCN firmware Version ENC: 1.23 DEC: 9 VEP: 0 Revision: 9
[Wed Sep 23 20:03:52 2026] amdgpu 0000:c5:00.0: amdgpu: reserve 0x8900000 from 0x8020000000 for PSP TMR
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: RAS: optional ras ta ucode is not available
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: RAP: optional rap ta ucode is not available
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: SECUREDISPLAY: optional securedisplay ta ucode is not available
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: SMU is initialized successfully!
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] Display Core v3.2.351 initialized on DCN 3.5
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DP-HDMI FRL PCON supported
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DMUB hardware initialized: version=0x09001B00
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] Using ACPI provided EDID for eDP-1
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] eDP-1: PSR support 1, DC PSR ver 0, sink PSR ver 4 DPCD caps 0x3a su_y_granularity 4
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] HDMI-A-1: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DP-1: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DP-2: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DP-3: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DP-4: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DP-5: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DP-6: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] DP-7: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: SE 1, SH per SE 2, CU per SH 8, active_cu_number 16
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring jpeg_dec_0 uses VM inv eng 1 on hub 8
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 13 on hub 0
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: ring vpe uses VM inv eng 4 on hub 8
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: Runtime PM not available
[Wed Sep 23 20:03:53 2026] amdgpu 0000:c5:00.0: amdgpu: [drm] Using custom brightness curve
[Wed Sep 23 20:03:53 2026] [drm] Initialized amdgpu 3.64.0 for 0000:c5:00.0 on minor 0
[Wed Sep 23 20:03:53 2026] [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed
[Wed Sep 23 20:03:53 2026] tsc: Refined TSC clocksource calibration: 1996.274 MHz
[Wed Sep 23 20:03:53 2026] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x398cdcbfcf5, max_idle_ns: 881590671833 ns
[Wed Sep 23 20:03:53 2026] clocksource: Switched to clocksource tsc
[Wed Sep 23 20:03:54 2026] Console: switching to colour frame buffer device 120x37
[Wed Sep 23 20:03:54 2026] amdgpu 0000:c5:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[Wed Sep 23 20:03:54 2026] brd: module loaded
[Wed Sep 23 20:03:54 2026] loop: module loaded
[Wed Sep 23 20:03:54 2026] nvme 0000:c1:00.0: platform quirk: setting simple suspend
[Wed Sep 23 20:03:54 2026] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[Wed Sep 23 20:03:54 2026] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[Wed Sep 23 20:03:54 2026] nvme nvme0: pci function 0000:c1:00.0
[Wed Sep 23 20:03:54 2026] r8169 0000:c3:00.0 eth0: RTL8168ep/8111ep, 7c:cf:0f:38:58:37, XID 502, IRQ 81
[Wed Sep 23 20:03:54 2026] r8169 0000:c3:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[Wed Sep 23 20:03:54 2026] r8169 0000:c3:00.0 eth0: DASH disabled
[Wed Sep 23 20:03:54 2026] mt7925e 0000:c2:00.0: enabling device (0000 -> 0002)
[Wed Sep 23 20:03:54 2026] mt7925e 0000:c2:00.0: ASIC revision: 79250000
[Wed Sep 23 20:03:54 2026] nvme nvme0: 24/0/0 default/read/poll queues
[Wed Sep 23 20:03:54 2026]  nvme0n1: p1 p2 p3
[Wed Sep 23 20:03:54 2026] wwan wwan0: port wwan0at0 attached
[Wed Sep 23 20:03:54 2026] wwan wwan0: port wwan0at1 attached
[Wed Sep 23 20:03:54 2026] wwan wwan1: port wwan1at0 attached
[Wed Sep 23 20:03:54 2026] wwan wwan1: port wwan1at1 attached
[Wed Sep 23 20:03:54 2026] wwan wwan2: port wwan2qcdm0 attached
[Wed Sep 23 20:03:54 2026] wwan wwan2: port wwan2mbim0 attached
[Wed Sep 23 20:03:54 2026] wwan wwan2: port wwan2at0 attached
[Wed Sep 23 20:03:54 2026] mt7925e 0000:c2:00.0: HW/SW Version: 0x8a108a10, Build Time: 20250305132908a

[Wed Sep 23 20:03:54 2026] usbcore: registered new device driver r8152-cfgselector
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver r8152
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver cdc_ether
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver rndis_host
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver cdc_ncm
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver r8153_ecm
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c5:00.4: xHCI Host Controller
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c5:00.4: new USB bus registered, assigned bus number 1
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c5:00.4: hcc params 0x0118ffc5 hci version 0x120 quirks 0x0000000200000010
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c5:00.4: xHCI Host Controller
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c5:00.4: new USB bus registered, assigned bus number 2
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c5:00.4: Host supports USB 3.1 Enhanced SuperSpeed
[Wed Sep 23 20:03:54 2026] hub 1-0:1.0: USB hub found
[Wed Sep 23 20:03:54 2026] hub 1-0:1.0: 1 port detected
[Wed Sep 23 20:03:54 2026] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[Wed Sep 23 20:03:54 2026] hub 2-0:1.0: USB hub found
[Wed Sep 23 20:03:54 2026] hub 2-0:1.0: 1 port detected
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.0: xHCI Host Controller
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.0: new USB bus registered, assigned bus number 3
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.0: hcc params 0x0128ffc5 hci version 0x120 quirks 0x0000000200000010
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.0: xHCI Host Controller
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.0: new USB bus registered, assigned bus number 4
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.0: Host supports USB 3.1 Enhanced SuperSpeed
[Wed Sep 23 20:03:54 2026] hub 3-0:1.0: USB hub found
[Wed Sep 23 20:03:54 2026] hub 3-0:1.0: 5 ports detected
[Wed Sep 23 20:03:54 2026] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[Wed Sep 23 20:03:54 2026] hub 4-0:1.0: USB hub found
[Wed Sep 23 20:03:54 2026] hub 4-0:1.0: 2 ports detected
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.3: xHCI Host Controller
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.3: new USB bus registered, assigned bus number 5
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.3: hcc params 0x0118ffc5 hci version 0x120 quirks 0x0000000200000010
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.3: xHCI Host Controller
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.3: new USB bus registered, assigned bus number 6
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.3: Host supports USB 3.1 Enhanced SuperSpeed
[Wed Sep 23 20:03:54 2026] hub 5-0:1.0: USB hub found
[Wed Sep 23 20:03:54 2026] hub 5-0:1.0: 1 port detected
[Wed Sep 23 20:03:54 2026] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[Wed Sep 23 20:03:54 2026] hub 6-0:1.0: USB hub found
[Wed Sep 23 20:03:54 2026] hub 6-0:1.0: 1 port detected
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.4: xHCI Host Controller
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.4: new USB bus registered, assigned bus number 7
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.4: hcc params 0x0118ffc5 hci version 0x120 quirks 0x0000000200000010
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.4: xHCI Host Controller
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.4: new USB bus registered, assigned bus number 8
[Wed Sep 23 20:03:54 2026] xhci_hcd 0000:c7:00.4: Host supports USB 3.1 Enhanced SuperSpeed
[Wed Sep 23 20:03:54 2026] hub 7-0:1.0: USB hub found
[Wed Sep 23 20:03:54 2026] hub 7-0:1.0: 1 port detected
[Wed Sep 23 20:03:54 2026] usb usb8: We don't know the algorithms for LPM for this host, disabling LPM.
[Wed Sep 23 20:03:54 2026] hub 8-0:1.0: USB hub found
[Wed Sep 23 20:03:54 2026] hub 8-0:1.0: 1 port detected
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver uas
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver usb-storage
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver pl2303
[Wed Sep 23 20:03:54 2026] usbserial: USB Serial support registered for pl2303
[Wed Sep 23 20:03:54 2026] i8042: PNP: PS/2 Controller [PNP0303:KBD] at 0x60,0x64 irq 1
[Wed Sep 23 20:03:54 2026] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[Wed Sep 23 20:03:54 2026] i8042: Warning: Keylock active
[Wed Sep 23 20:03:54 2026] serio: i8042 KBD port at 0x60,0x64 irq 1
[Wed Sep 23 20:03:54 2026] mousedev: PS/2 mouse device common for all mice
[Wed Sep 23 20:03:54 2026] rtc_cmos PNP0B00:00: error -ENXIO: IRQ index 0 not found
[Wed Sep 23 20:03:54 2026] rtc_cmos PNP0B00:00: RTC can wake from S4
[Wed Sep 23 20:03:54 2026] rtc_cmos PNP0B00:00: registered as rtc0
[Wed Sep 23 20:03:54 2026] rtc_cmos PNP0B00:00: setting system clock to 2026-09-23T18:03:49 UTC (1790186629)
[Wed Sep 23 20:03:54 2026] rtc_cmos PNP0B00:00: no alarms, y3k, 114 bytes nvram
[Wed Sep 23 20:03:54 2026] piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0
[Wed Sep 23 20:03:54 2026] piix4_smbus 0000:00:14.0: Using register 0x02 for SMBus port selection
[Wed Sep 23 20:03:54 2026] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[Wed Sep 23 20:03:54 2026] piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20
[Wed Sep 23 20:03:54 2026] i2c i2c-22: Successfully instantiated SPD at 0x50
[Wed Sep 23 20:03:54 2026] i2c i2c-22: Successfully instantiated SPD at 0x51
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver uvcvideo
[Wed Sep 23 20:03:54 2026] device-mapper: ioctl: 4.50.0-ioctl (2025-04-28) initialised: dm-devel@lists.linux.dev
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver btusb
[Wed Sep 23 20:03:54 2026] ccp 0000:c5:00.2: enabling device (0000 -> 0002)
[Wed Sep 23 20:03:54 2026] ccp 0000:c5:00.2: tee enabled
[Wed Sep 23 20:03:54 2026] ccp 0000:c5:00.2: psp: TSME enabled
[Wed Sep 23 20:03:54 2026] ccp 0000:c5:00.2: psp enabled
[Wed Sep 23 20:03:54 2026] hid: raw HID events driver (C) Jiri Kosina
[Wed Sep 23 20:03:54 2026] usbcore: registered new interface driver usbhid
[Wed Sep 23 20:03:54 2026] usbhid: USB HID core driver
[Wed Sep 23 20:03:54 2026] input: ELAN0688:00 04F3:320B Mouse as /devices/platform/AMDI0010:01/i2c-1/i2c-ELAN0688:00/0018:04F3:320B.0001/input/input5
[Wed Sep 23 20:03:54 2026] input: ELAN0688:00 04F3:320B Touchpad as /devices/platform/AMDI0010:01/i2c-1/i2c-ELAN0688:00/0018:04F3:320B.0001/input/input7
[Wed Sep 23 20:03:54 2026] hid-multitouch 0018:04F3:320B.0001: input,hidraw0: I2C HID v1.00 Mouse [ELAN0688:00 04F3:320B] on i2c-ELAN0688:00
[Wed Sep 23 20:03:54 2026] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[Wed Sep 23 20:03:54 2026] usb 3-2: new full-speed USB device number 2 using xhci_hcd
[Wed Sep 23 20:03:54 2026] mt7925e 0000:c2:00.0: WM Firmware Version: ____000000, Build Time: 20250305133013
[Wed Sep 23 20:03:54 2026] usb 6-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[Wed Sep 23 20:03:54 2026] scsi host0: uas
[Wed Sep 23 20:03:54 2026] scsi 0:0:0:0: Direct-Access     Samsung  PSSD T9          0    PQ: 0 ANSI: 6
[Wed Sep 23 20:03:54 2026] sd 0:0:0:0: Attached scsi generic sg0 type 0
[Wed Sep 23 20:03:54 2026] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[Wed Sep 23 20:03:54 2026] sd 0:0:0:0: [sda] Write Protect is off
[Wed Sep 23 20:03:54 2026] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[Wed Sep 23 20:03:54 2026] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[Wed Sep 23 20:03:54 2026] input: Logitech Dell Wireless Mouse WM123 as /devices/pci0000:00/0000:00:08.3/0000:c7:00.0/usb3/3-2/3-2:1.0/0003:046D:C535.0002/input/input8
[Wed Sep 23 20:03:54 2026] hid-generic 0003:046D:C535.0002: input,hidraw1: USB HID v1.11 Mouse [Logitech Dell Wireless Mouse WM123] on usb-0000:c7:00.0-2/input0
[Wed Sep 23 20:03:54 2026] input: Logitech Dell Wireless Mouse WM123 Consumer Control as /devices/pci0000:00/0000:00:08.3/0000:c7:00.0/usb3/3-2/3-2:1.1/0003:046D:C535.0003/input/input9
[Wed Sep 23 20:03:54 2026] uvcvideo 1-1:1.0: Found UVC 1.50 device Integrated RGB Camera (30c9:00f4)
[Wed Sep 23 20:03:54 2026] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
[Wed Sep 23 20:03:54 2026] sd 0:0:0:0: [sda] Optimal transfer size 2097152 bytes
[Wed Sep 23 20:03:54 2026] uvcvideo 1-1:1.2: Found UVC 1.50 device Integrated RGB Camera (30c9:00f4)
[Wed Sep 23 20:03:54 2026]  sda: sda1 sda2
[Wed Sep 23 20:03:54 2026] sd 0:0:0:0: [sda] Attached SCSI disk
[Wed Sep 23 20:03:54 2026] hid-generic 0003:046D:C535.0003: input,hidraw2: USB HID v1.11 Device [Logitech Dell Wireless Mouse WM123] on usb-0000:c7:00.0-2/input1
[Wed Sep 23 20:03:55 2026] usb 3-5: new high-speed USB device number 3 using xhci_hcd
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: ThinkPad ACPI Extras v0.26
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: http://ibm-acpi.sf.net/
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: ThinkPad BIOS R2XET40W (1.20 ), EC R2XHT33W
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: Lenovo ThinkPad P16s Gen 4 AMD, model 21RXS07D00
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: radio switch found; radios are enabled
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: volume: disabled as there is no ALSA support in this kernel
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: secondary fan control detected & enabled
[Wed Sep 23 20:03:55 2026] thinkpad_acpi: battery 1 registered (start 40, stop 80, behaviours: 0xb)
[Wed Sep 23 20:03:55 2026] ACPI: battery: new hook: ThinkPad Battery Extension
[Wed Sep 23 20:03:55 2026] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input12
[Wed Sep 23 20:03:55 2026] usbcore: registered new interface driver snd-usb-audio
[Wed Sep 23 20:03:55 2026] snd_acp_pci 0000:c5:00.5: enabling device (0000 -> 0002)
[Wed Sep 23 20:03:55 2026] snd_hda_intel 0000:c5:00.1: probe with driver snd_hda_intel failed with error -2
[Wed Sep 23 20:03:55 2026] NET: Registered PF_PACKET protocol family
[Wed Sep 23 20:03:55 2026] Bluetooth: RFCOMM socket layer initialized
[Wed Sep 23 20:03:55 2026] Bluetooth: RFCOMM ver 1.11
[Wed Sep 23 20:03:55 2026] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[Wed Sep 23 20:03:55 2026] Bluetooth: BNEP socket layer initialized
[Wed Sep 23 20:03:55 2026] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[Wed Sep 23 20:03:55 2026] Bluetooth: HIDP socket layer initialized
[Wed Sep 23 20:03:55 2026] x86/amd: Previous system reset reason [0x00080800]: software wrote 0x6 to reset control register 0xCF9
[Wed Sep 23 20:03:55 2026] microcode: Current revision: 0x0b204037
[Wed Sep 23 20:03:55 2026] IPI shorthand broadcast: enabled
[Wed Sep 23 20:03:55 2026] sched_clock: Marking stable (3239311288, 524145)->(3243114726, -3279293)
[Wed Sep 23 20:03:55 2026] registered taskstats version 1
[Wed Sep 23 20:03:55 2026] Loading compiled-in X.509 certificates
[Wed Sep 23 20:03:55 2026] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[Wed Sep 23 20:03:55 2026] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[Wed Sep 23 20:03:55 2026] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[Wed Sep 23 20:03:55 2026] clk: Disabling unused clocks
[Wed Sep 23 20:03:55 2026] PM: genpd: Disabling unused power domains
[Wed Sep 23 20:03:55 2026] ALSA device list:
[Wed Sep 23 20:03:55 2026]   No soundcards found.
[Wed Sep 23 20:03:55 2026] check access for rdinit=/init failed: -2, ignoring
[Wed Sep 23 20:03:55 2026] RAMDISK: xz image found at block 0
[Wed Sep 23 20:03:55 2026] snd_hda_codec_alc269 hdaudioC0D0: ALC257: picked fixup  for PCI SSID 17aa:0000
[Wed Sep 23 20:03:55 2026] snd_hda_codec_alc269 hdaudioC0D0: autoconfig for ALC257: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[Wed Sep 23 20:03:55 2026] snd_hda_codec_alc269 hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[Wed Sep 23 20:03:55 2026] snd_hda_codec_alc269 hdaudioC0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[Wed Sep 23 20:03:55 2026] snd_hda_codec_alc269 hdaudioC0D0:    mono: mono_out=0x0
[Wed Sep 23 20:03:55 2026] snd_hda_codec_alc269 hdaudioC0D0:    inputs:
[Wed Sep 23 20:03:55 2026] snd_hda_codec_alc269 hdaudioC0D0:      Mic=0x19
[Wed Sep 23 20:03:55 2026] input: HD-Audio Generic Mic as /devices/pci0000:00/0000:00:08.1/0000:c5:00.6/sound/card0/input13
[Wed Sep 23 20:03:55 2026] input: HD-Audio Generic Headphone as /devices/pci0000:00/0000:00:08.1/0000:c5:00.6/sound/card0/input14
[Wed Sep 23 20:03:55 2026] hub 3-5:1.0: USB hub found
[Wed Sep 23 20:03:55 2026] hub 3-5:1.0: 2 ports detected
[Wed Sep 23 20:03:55 2026] EXT4-fs (ram0): mounted filesystem 7cb28bf0-7aa6-44b7-94a5-586784d7afbc r/w without journal. Quota mode: disabled.
[Wed Sep 23 20:03:55 2026] VFS: Mounted root (ext4 filesystem) on device 1:0.
[Wed Sep 23 20:03:55 2026] devtmpfs: mounted
[Wed Sep 23 20:03:55 2026] Freeing unused kernel image (initmem) memory: 2060K
[Wed Sep 23 20:03:55 2026] Write protecting the kernel read-only data: 32768k
[Wed Sep 23 20:03:55 2026] Freeing unused kernel image (text/rodata gap) memory: 1252K
[Wed Sep 23 20:03:55 2026] Freeing unused kernel image (rodata/data gap) memory: 496K
[Wed Sep 23 20:03:55 2026] Run /sbin/init as init process
[Wed Sep 23 20:03:55 2026]   with arguments:
[Wed Sep 23 20:03:55 2026]     /sbin/init
[Wed Sep 23 20:03:55 2026]     3
[Wed Sep 23 20:03:55 2026]   with environment:
[Wed Sep 23 20:03:55 2026]     HOME=/
[Wed Sep 23 20:03:55 2026]     TERM=linux
[Wed Sep 23 20:03:55 2026] EXT4-fs (nvme0n1p1): mounted filesystem 2df28219-71a6-40b9-b198-f03d766d674b ro with ordered data mode. Quota mode: disabled.
[Wed Sep 23 20:03:55 2026] EXT4-fs (ram0): unmounting filesystem 7cb28bf0-7aa6-44b7-94a5-586784d7afbc.
[Wed Sep 23 20:03:55 2026] EXT4-fs (nvme0n1p1): re-mounted 2df28219-71a6-40b9-b198-f03d766d674b.
[Wed Sep 23 20:03:55 2026] usb 3-5.1: new high-speed USB device number 4 using xhci_hcd
[Wed Sep 23 20:03:55 2026] EXT4-fs (nvme0n1p1): re-mounted 2df28219-71a6-40b9-b198-f03d766d674b r/w.
[Wed Sep 23 20:03:55 2026] EXT4-fs (nvme0n1p2): mounted filesystem 8a0c3093-5dbf-4951-a6ff-baffd21a8822 r/w with ordered data mode. Quota mode: disabled.
[Wed Sep 23 20:03:55 2026] EXT4-fs (nvme0n1p3): mounted filesystem 46600c45-d5f0-4d4a-b806-a2045dd52d92 r/w with ordered data mode. Quota mode: disabled.
[Wed Sep 23 20:03:55 2026] Bluetooth: hci0: Failed to register coredump (-95)
[Wed Sep 23 20:03:55 2026] Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20250305133215
[Wed Sep 23 20:03:56 2026] Bluetooth: hci0: Device setup in 375136 usecs
[Wed Sep 23 20:03:56 2026] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
[Wed Sep 23 20:03:56 2026] Bluetooth: MGMT ver 1.23
[Wed Sep 23 20:03:59 2026] wlan0: authenticate with 04:f0:21:bd:8f:40 (local address=08:a1:36:21:4d:5d)
[Wed Sep 23 20:04:00 2026] wlan0: send auth to 04:f0:21:bd:8f:40 (try 1/3)
[Wed Sep 23 20:04:00 2026] wlan0: authenticated
[Wed Sep 23 20:04:00 2026] wlan0: associate with 04:f0:21:bd:8f:40 (try 1/3)
[Wed Sep 23 20:04:00 2026] wlan0: RX AssocResp from 04:f0:21:bd:8f:40 (capab=0x11 status=0 aid=2)
[Wed Sep 23 20:04:00 2026] wlan0: associated
[Wed Sep 23 20:07:33 2026] PM: suspend entry (s2idle)
[Wed Sep 23 20:07:33 2026] Filesystems sync: 0.010 seconds
[Wed Sep 23 20:07:33 2026] Freezing user space processes
[Wed Sep 23 20:07:33 2026] Freezing user space processes completed (elapsed 0.001 seconds)
[Wed Sep 23 20:07:33 2026] OOM killer disabled.
[Wed Sep 23 20:07:33 2026] Freezing remaining freezable tasks
[Wed Sep 23 20:07:33 2026] Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
[Wed Sep 23 20:07:33 2026] printk: Suspending console(s) (use no_console_suspend to debug)
[Wed Sep 23 20:07:33 2026] GFP mask restricted
[Wed Sep 23 20:07:33 2026] wlan0: deauthenticating from 04:f0:21:bd:8f:40 by local choice (Reason: 3=DEAUTH_LEAVING)
[Wed Sep 23 20:07:33 2026] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[Wed Sep 23 20:07:34 2026] PM: suspend of devices complete after 986.367 msecs
[Wed Sep 23 20:07:34 2026] PM: start suspend of devices complete after 987.677 msecs
[Wed Sep 23 20:07:34 2026] Clearing debounce for GPIO #0 during suspend.
[Wed Sep 23 20:07:34 2026] Disabling GPIO #8 interrupt for suspend.
[Wed Sep 23 20:07:34 2026] PM: late suspend of devices complete after 1.005 msecs
[Wed Sep 23 20:07:34 2026] Setting wake for GPIO 8 to enable
[Wed Sep 23 20:07:34 2026] ACPI: EC: interrupt blocked
[Wed Sep 23 20:07:34 2026] PM: Triggering wakeup from IRQ 9
[Wed Sep 23 20:07:34 2026] PM: noirq suspend of devices complete after 136.979 msecs
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP4: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP9: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP6: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GP10: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP0.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP1.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP4.SDCR: LPI: Constraint not met; min power state:D3hot current power state:D0
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP5.WLAN: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP6.RTL8: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPP6.RUSB: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPPA.HDAU: LPI: Constraint not met; min power state:D3hot current power state:D0
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PCI0.GPPB.IPU_: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C000: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C001: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C002: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C003: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C004: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C005: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C006: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C007: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C008: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C009: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C00A: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C00B: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C00C: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C00D: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C00E: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C00F: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C010: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C011: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C012: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C013: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C014: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C015: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C016: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PLTF.C017: LPI: Device not power manageable
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PEP_: Successfully transitioned to state screen off
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 ms entry
[Wed Sep 23 20:07:34 2026] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 entry
[Wed Sep 23 20:07:34 2026] PM: suspend-to-idle
[Wed Sep 23 20:07:34 2026] ACPI: EC: ACPI EC GPE status set
[Wed Sep 23 20:07:34 2026] ACPI: PM: Rearming ACPI SCI for wakeup
[Wed Sep 23 20:07:34 2026] amd_pmc: SMU idlemask s0i3: 0xffff9afd
[Wed Sep 23 20:07:35 2026] Timekeeping suspended for 0.426 seconds
[Wed Sep 23 20:07:35 2026] PM: Triggering wakeup from IRQ 9
[Wed Sep 23 20:07:35 2026] ACPI: EC: ACPI EC GPE status set
[Wed Sep 23 20:07:35 2026] ACPI: EC: ACPI EC GPE dispatched
[Wed Sep 23 20:07:35 2026] ACPI: EC: ACPI EC work flushed
[Wed Sep 23 20:07:35 2026] ACPI: PM: Rearming ACPI SCI for wakeup
[Wed Sep 23 20:07:35 2026] PM: Triggering wakeup from IRQ 9
[Wed Sep 23 20:07:35 2026] amd_pmc: SMU idlemask s0i3: 0xffff9abd
[Wed Sep 23 20:07:35 2026] ACPI: EC: ACPI EC GPE status set
[Wed Sep 23 20:07:35 2026] ACPI: PM: Rearming ACPI SCI for wakeup
[Wed Sep 23 20:07:35 2026] amd_pmc: SMU idlemask s0i3: 0xffff9abd
[Wed Sep 23 20:07:38 2026] Timekeeping suspended for 2.997 seconds
[Wed Sep 23 20:07:38 2026] PM: Triggering wakeup from IRQ 9
[Wed Sep 23 20:07:38 2026] ACPI: EC: ACPI EC GPE status set
[Wed Sep 23 20:07:38 2026] ACPI: EC: ACPI EC GPE dispatched
[Wed Sep 23 20:07:38 2026] PM: Triggering wakeup from IRQ 7
[Wed Sep 23 20:07:38 2026] ACPI: EC: ACPI EC work flushed
[Wed Sep 23 20:07:38 2026] ACPI: PM: Wakeup after ACPI Notify sync
[Wed Sep 23 20:07:38 2026] PM: resume from suspend-to-idle
[Wed Sep 23 20:07:38 2026] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 exit
[Wed Sep 23 20:07:38 2026] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 ms exit
[Wed Sep 23 20:07:38 2026] ACPI: \_SB_.PEP_: Successfully transitioned to state screen on
[Wed Sep 23 20:07:38 2026] ACPI: EC: interrupt unblocked
[Wed Sep 23 20:07:39 2026] PM: noirq resume of devices complete after 627.704 msecs
[Wed Sep 23 20:07:39 2026] Setting wake for GPIO 8 to disable
[Wed Sep 23 20:07:39 2026] PM: early resume of devices complete after 2.694 msecs
[Wed Sep 23 20:07:39 2026] [drm] PCIE GART of 512M enabled (table at 0x0000008000900000).
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: SMU is resuming...
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: SMU is resumed successfully!
[Wed Sep 23 20:07:39 2026] nvme nvme0: 24/0/0 default/read/poll queues
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring jpeg_dec_0 uses VM inv eng 1 on hub 8
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 13 on hub 0
[Wed Sep 23 20:07:39 2026] amdgpu 0000:c5:00.0: amdgpu: ring vpe uses VM inv eng 4 on hub 8
[Wed Sep 23 20:07:39 2026] PM: resume of devices complete after 240.813 msecs
[Wed Sep 23 20:07:39 2026] GFP mask restored
[Wed Sep 23 20:07:39 2026] OOM killer enabled.
[Wed Sep 23 20:07:39 2026] Restarting tasks: Starting
[Wed Sep 23 20:07:39 2026] Restarting tasks: Done
[Wed Sep 23 20:07:39 2026] random: crng reseeded on system resumption
[Wed Sep 23 20:07:39 2026] PM: suspend exit
[Wed Sep 23 20:07:43 2026] wlan0: authenticate with 04:f0:21:bd:8f:40 (local address=08:a1:36:21:4d:5d)
[Wed Sep 23 20:07:43 2026] wlan0: send auth to 04:f0:21:bd:8f:40 (try 1/3)
[Wed Sep 23 20:07:43 2026] wlan0: authenticated
[Wed Sep 23 20:07:43 2026] wlan0: associate with 04:f0:21:bd:8f:40 (try 1/3)
[Wed Sep 23 20:07:43 2026] wlan0: RX AssocResp from 04:f0:21:bd:8f:40 (capab=0x11 status=0 aid=2)
[Wed Sep 23 20:07:43 2026] wlan0: associated
[Wed Sep 23 20:07:52 2026] NOTICE: Automounting of tracing to debugfs is deprecated and will be removed in 2030

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

[Mario Limonciello]

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.

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

[Fourhundred Thecat]

On 2026-09-23 20:57, Mario Limonciello wrote:
> 
> 
> 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.

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

That commit is in my tree, but the message does not appear. Booted with 
the IOMMU enabled, 24 CPUs, no IOMMU parameters, the only thing matching 
is the unrelated generic ACPI one:

   dmesg | grep -iE 'FW_BUG|Firmware Bug|matched UID|MSFT0201|acpihid'
   AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
   ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
   platform MSFT0201:00: Adding to iommu group 0

No "No ACPI device matched UID, but N device(s) matched HID." The UIDs 
agree on this machine:

   IVRS:  hid:MSFT0201, uid:1, rdevid:0x60
   ACPI:  MSFT0201:00, _UID = 1, path \_SB_.MHSP

so get_acpihid_device_id() matches on the first pass and fw_bug is never 
set. Same device path as in your commit, but this BIOS appears to have 
consistent UIDs.

The full AMD-Vi block for this boot:

   ACPI: IVRS 0x000000006B1BF000 0001F6 (v02 LENOVO TP-R2X   00001200 
PTEC 00000002)
   AMD-Vi: ivrs, add hid:AMDI0020, uid:ID00, rdevid:0xa0
   AMD-Vi: ivrs, add hid:AMDI0020, uid:ID01, rdevid:0xa0
   AMD-Vi: ivrs, add hid:AMDI0020, uid:ID02, rdevid:0xa0
   AMD-Vi: ivrs, add hid:AMDI0020, uid:ID03, rdevid:0x98
   AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
   AMD-Vi: ivrs, add hid:AMDI0020, uid:ID04, rdevid:0x98
   AMD-Vi: Using global IVHD EFR:0x246577efa2254afa, EFR2:0x10
   pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
   AMD-Vi: Extended features (0x246577efa2254afa, 0x10): PPR NX GT [5] 
IA GA PC GA_vAPIC
   AMD-Vi: Interrupt remapping enabled
   AMD-Vi: Virtual APIC enabled

One thing that may be worth your attention anyway: MSFT0201:00 is the 
only ACPI HID device in any IOMMU group on this system, alone in group 
0. It is not the TPM - tpm0 is MSFT0101:00. So the single non-PCI device 
the IOMMU manages here is Pluton.

For what it is worth, when I tested with PlutonSecurityProcessor set to 
Disable earlier in this thread the machine still failed to wake, though 
I did not check at the time whether MSFT0201 was still present in the 
IVRS in that configuration. I can re-run that combination and capture 
the IVRS block if it would help.

 > I think you're missing commit e9f850ba66cd.

You are right. My 6.18.51 tree still has the old code:

   drivers/rtc/rtc-cmos.c:1502:  irq = platform_get_irq(pdev, 0);

which is exactly the path that produces the "-ENXIO: IRQ index 0 not 
found" message I quoted. I will cherry-pick it and report back whether 
the wakealarm shows up. If it does, all further cycles can be timed 
rather than woken by hand, which will make the failing case much easier 
to instrument.

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

OK. I will go through BIOS setup by hand and look for anything 
controlling storage link power or D3, rather than relying on the 
think-lmi attribute list.

The 7.3-rc4 test is still queued and I will report the same data from it.

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

[Mario Limonciello]

On 9/23/26 14:13, Fourhundred Thecat wrote:
> On 2026-09-23 20:57, Mario Limonciello wrote:
>>
>>
>> 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.
> 
>  > I am specifically expecting the message from 51c33f333bbf to come up 
> and want to confirm that.
> 
> That commit is in my tree, but the message does not appear. Booted with 
> the IOMMU enabled, 24 CPUs, no IOMMU parameters, the only thing matching 
> is the unrelated generic ACPI one:
> 
>    dmesg | grep -iE 'FW_BUG|Firmware Bug|matched UID|MSFT0201|acpihid'
>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
>    ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
>    platform MSFT0201:00: Adding to iommu group 0
> 
> No "No ACPI device matched UID, but N device(s) matched HID." The UIDs 
> agree on this machine:
> 
>    IVRS:  hid:MSFT0201, uid:1, rdevid:0x60
>    ACPI:  MSFT0201:00, _UID = 1, path \_SB_.MHSP
> 
> so get_acpihid_device_id() matches on the first pass and fw_bug is never 
> set. Same device path as in your commit, but this BIOS appears to have 
> consistent UIDs.
> 
> The full AMD-Vi block for this boot:
> 
>    ACPI: IVRS 0x000000006B1BF000 0001F6 (v02 LENOVO TP-R2X   00001200 
> PTEC 00000002)
>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID00, rdevid:0xa0
>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID01, rdevid:0xa0
>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID02, rdevid:0xa0
>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID03, rdevid:0x98
>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID04, rdevid:0x98
>    AMD-Vi: Using global IVHD EFR:0x246577efa2254afa, EFR2:0x10
>    pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
>    AMD-Vi: Extended features (0x246577efa2254afa, 0x10): PPR NX GT [5] 
> IA GA PC GA_vAPIC
>    AMD-Vi: Interrupt remapping enabled
>    AMD-Vi: Virtual APIC enabled
> 
> One thing that may be worth your attention anyway: MSFT0201:00 is the 
> only ACPI HID device in any IOMMU group on this system, alone in group 
> 0. It is not the TPM - tpm0 is MSFT0101:00. So the single non-PCI device 
> the IOMMU manages here is Pluton.
> 

Got it.  Then this is likely not a Pluton/TPM related issue as it 
originally seemed as the BIOS has that UID aligned.

> For what it is worth, when I tested with PlutonSecurityProcessor set to 
> Disable earlier in this thread the machine still failed to wake, though 
> I did not check at the time whether MSFT0201 was still present in the 
> IVRS in that configuration. I can re-run that combination and capture 
> the IVRS block if it would help.
> 
>  > I think you're missing commit e9f850ba66cd.
> 
> You are right. My 6.18.51 tree still has the old code:
> 
>    drivers/rtc/rtc-cmos.c:1502:  irq = platform_get_irq(pdev, 0);
> 
> which is exactly the path that produces the "-ENXIO: IRQ index 0 not 
> found" message I quoted. I will cherry-pick it and report back whether 
> the wakealarm shows up. If it does, all further cycles can be timed 
> rather than woken by hand, which will make the failing case much easier 
> to instrument.

Good.

> 
>  > I don't know for sure if Think LMI will export all BIOS options in 
> the BIOS GUI.
> 
> OK. I will go through BIOS setup by hand and look for anything 
> controlling storage link power or D3, rather than relying on the think- 
> lmi attribute list.
> 

OK

> The 7.3-rc4 test is still queued and I will report the same data from it.

OK

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

[Fourhundred Thecat]

On 2026-09-23 21:20, Mario Limonciello wrote:
> 
> 
> On 9/23/26 14:13, Fourhundred Thecat wrote:
>> On 2026-09-23 20:57, Mario Limonciello wrote:
>>>
>>>
>>> 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.
>>
>>  > I am specifically expecting the message from 51c33f333bbf to come 
>> up and want to confirm that.
>>
>> That commit is in my tree, but the message does not appear. Booted 
>> with the IOMMU enabled, 24 CPUs, no IOMMU parameters, the only thing 
>> matching is the unrelated generic ACPI one:
>>
>>    dmesg | grep -iE 'FW_BUG|Firmware Bug|matched UID|MSFT0201|acpihid'
>>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
>>    ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
>>    platform MSFT0201:00: Adding to iommu group 0
>>
>> No "No ACPI device matched UID, but N device(s) matched HID." The UIDs 
>> agree on this machine:
>>
>>    IVRS:  hid:MSFT0201, uid:1, rdevid:0x60
>>    ACPI:  MSFT0201:00, _UID = 1, path \_SB_.MHSP
>>
>> so get_acpihid_device_id() matches on the first pass and fw_bug is 
>> never set. Same device path as in your commit, but this BIOS appears 
>> to have consistent UIDs.
>>
>> The full AMD-Vi block for this boot:
>>
>>    ACPI: IVRS 0x000000006B1BF000 0001F6 (v02 LENOVO TP-R2X   00001200 
>> PTEC 00000002)
>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID00, rdevid:0xa0
>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID01, rdevid:0xa0
>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID02, rdevid:0xa0
>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID03, rdevid:0x98
>>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID04, rdevid:0x98
>>    AMD-Vi: Using global IVHD EFR:0x246577efa2254afa, EFR2:0x10
>>    pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
>>    AMD-Vi: Extended features (0x246577efa2254afa, 0x10): PPR NX GT [5] 
>> IA GA PC GA_vAPIC
>>    AMD-Vi: Interrupt remapping enabled
>>    AMD-Vi: Virtual APIC enabled
>>
>> One thing that may be worth your attention anyway: MSFT0201:00 is the 
>> only ACPI HID device in any IOMMU group on this system, alone in group 
>> 0. It is not the TPM - tpm0 is MSFT0101:00. So the single non-PCI 
>> device the IOMMU manages here is Pluton.
>>
> 
> Got it.  Then this is likely not a Pluton/TPM related issue as it 
> originally seemed as the BIOS has that UID aligned.
> 
>> For what it is worth, when I tested with PlutonSecurityProcessor set 
>> to Disable earlier in this thread the machine still failed to wake, 
>> though I did not check at the time whether MSFT0201 was still present 
>> in the IVRS in that configuration. I can re-run that combination and 
>> capture the IVRS block if it would help.
>>
>>  > I think you're missing commit e9f850ba66cd.
>>

e9f850ba66cd works, thank you. With it applied I get 
/sys/class/rtc/rtc0/wakealarm and the -ENXIO message is gone:

   rtc_cmos PNP0B00:00: RTC can wake from S4
   rtc_cmos PNP0B00:00: registered as rtc0
   rtc_cmos PNP0B00:00: alarms up to one month, y3k, 114 bytes nvram
   8: ... IO-APIC 8-edge rtc0

With amd_iommu=off and all 24 CPUs I now get fully unattended timed cycles:

   pm_wakeup_irq:        9
   Last S0i3 Status:     Success
   Time (in us) to S0i3: 430540
   Residency Time:       13282379
   last_hw_sleep:        13282379
   ff_rt_clk:            incremented on each cycle

One small platform note in case it is useful to you: IRQ 8 never fires 
on this machine while the system is running. If I arm an alarm and poll, 
the alarm counts down and expires exactly on schedule but the IRQ 8 
counter stays at zero:

   t=0   arming +8       irq8=0
   t=1-7 wakealarm=1790194169   irq8=0
   t=8   wakealarm=''           irq8=0
   t=15  wakealarm=''           irq8=0

Identical with the IOMMU on and off, so it is not an interrupt remapping 
effect. The wake itself comes through the ACPI fixed-feature RTC event 
rather than IRQ 8, which is why it works anyway: ff_rt_clk increments 
and pm_wakeup_irq reports 9. IRQ 8 does register a single count at 
resume time.

Now the part that matters. With the IOMMU enabled and all 24 CPUs, the 
same timed suspend does not wake. Recorded before the cycle:

   === 2026-09-23T22:15:02 BEFORE
   cmdline:     (no iommu parameters)
   cpus online: 0-23
   iommu:       ivhd0
   ff_rt_clk:   0
   S0ix Entry Time: 0
   S0ix Exit Time: 0
   Residency Time: 0
   suspending with +30s alarm

Nothing was written after that. The machine never resumed and needed a 
forced power off.

So with the IOMMU enabled, every independent wake mechanism on this 
machine has now been tried and none of them work:

   lid switch (PNP0C0D)                          no wake
   internal keyboard (i8042, via AMD GPIO)       no wake
   power button (ACPI fixed feature)             no wake
   USB mouse, wakeup armed on device and hub     no wake
   ACPI fixed-feature RTC alarm                  no wake

The last one seems the most pointed to me. The RTC alarm wakes the 
machine through the ACPI SCI on IRQ 9, and that is exactly the path that 
works when amd_iommu=off - pm_wakeup_irq reports 9 on every successful 
cycle. With the IOMMU enabled the same mechanism produces nothing at 
all, and ff_rt_clk stays at 0 across the attempt.

Still to come: the 7.3-rc4 test, and a manual walk through BIOS setup 
looking for storage link power or D3 controls that think-lmi does not 
export.

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

[Fourhundred Thecat]

On 2026-09-23 22:26, Fourhundred Thecat wrote:
> On 2026-09-23 21:20, Mario Limonciello wrote:
>>
>>
>> On 9/23/26 14:13, Fourhundred Thecat wrote:
>>> On 2026-09-23 20:57, Mario Limonciello wrote:
>>>>
>>>>
>>>> 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.
>>>
>>>  > I am specifically expecting the message from 51c33f333bbf to come 
>>> up and want to confirm that.
>>>
>>> That commit is in my tree, but the message does not appear. Booted 
>>> with the IOMMU enabled, 24 CPUs, no IOMMU parameters, the only thing 
>>> matching is the unrelated generic ACPI one:
>>>
>>>    dmesg | grep -iE 'FW_BUG|Firmware Bug|matched UID|MSFT0201|acpihid'
>>>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
>>>    ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
>>>    platform MSFT0201:00: Adding to iommu group 0
>>>
>>> No "No ACPI device matched UID, but N device(s) matched HID." The 
>>> UIDs agree on this machine:
>>>
>>>    IVRS:  hid:MSFT0201, uid:1, rdevid:0x60
>>>    ACPI:  MSFT0201:00, _UID = 1, path \_SB_.MHSP
>>>
>>> so get_acpihid_device_id() matches on the first pass and fw_bug is 
>>> never set. Same device path as in your commit, but this BIOS appears 
>>> to have consistent UIDs.
>>>
>>> The full AMD-Vi block for this boot:
>>>
>>>    ACPI: IVRS 0x000000006B1BF000 0001F6 (v02 LENOVO TP-R2X   00001200 
>>> PTEC 00000002)
>>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID00, rdevid:0xa0
>>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID01, rdevid:0xa0
>>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID02, rdevid:0xa0
>>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID03, rdevid:0x98
>>>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
>>>    AMD-Vi: ivrs, add hid:AMDI0020, uid:ID04, rdevid:0x98
>>>    AMD-Vi: Using global IVHD EFR:0x246577efa2254afa, EFR2:0x10
>>>    pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
>>>    AMD-Vi: Extended features (0x246577efa2254afa, 0x10): PPR NX GT 
>>> [5] IA GA PC GA_vAPIC
>>>    AMD-Vi: Interrupt remapping enabled
>>>    AMD-Vi: Virtual APIC enabled
>>>
>>> One thing that may be worth your attention anyway: MSFT0201:00 is the 
>>> only ACPI HID device in any IOMMU group on this system, alone in 
>>> group 0. It is not the TPM - tpm0 is MSFT0101:00. So the single 
>>> non-PCI device the IOMMU manages here is Pluton.
>>>
>>
>> Got it.  Then this is likely not a Pluton/TPM related issue as it 
>> originally seemed as the BIOS has that UID aligned.
>>
>>> For what it is worth, when I tested with PlutonSecurityProcessor set 
>>> to Disable earlier in this thread the machine still failed to wake, 
>>> though I did not check at the time whether MSFT0201 was still present 
>>> in the IVRS in that configuration. I can re-run that combination and 
>>> capture the IVRS block if it would help.
>>>
>>>  > I think you're missing commit e9f850ba66cd.
>>>
> 
> e9f850ba66cd works, thank you. With it applied I get 
> /sys/class/rtc/rtc0/wakealarm and the -ENXIO message is gone:
> 
>    rtc_cmos PNP0B00:00: RTC can wake from S4
>    rtc_cmos PNP0B00:00: registered as rtc0
>    rtc_cmos PNP0B00:00: alarms up to one month, y3k, 114 bytes nvram
>    8: ... IO-APIC 8-edge rtc0
> 
> With amd_iommu=off and all 24 CPUs I now get fully unattended timed cycles:
> 
>    pm_wakeup_irq:        9
>    Last S0i3 Status:     Success
>    Time (in us) to S0i3: 430540
>    Residency Time:       13282379
>    last_hw_sleep:        13282379
>    ff_rt_clk:            incremented on each cycle
> 
> One small platform note in case it is useful to you: IRQ 8 never fires 
> on this machine while the system is running. If I arm an alarm and poll, 
> the alarm counts down and expires exactly on schedule but the IRQ 8 
> counter stays at zero:
> 
>    t=0   arming +8       irq8=0
>    t=1-7 wakealarm=1790194169   irq8=0
>    t=8   wakealarm=''           irq8=0
>    t=15  wakealarm=''           irq8=0
> 
> Identical with the IOMMU on and off, so it is not an interrupt remapping 
> effect. The wake itself comes through the ACPI fixed-feature RTC event 
> rather than IRQ 8, which is why it works anyway: ff_rt_clk increments 
> and pm_wakeup_irq reports 9. IRQ 8 does register a single count at 
> resume time.
> 
> Now the part that matters. With the IOMMU enabled and all 24 CPUs, the 
> same timed suspend does not wake. Recorded before the cycle:
> 
>    === 2026-09-23T22:15:02 BEFORE
>    cmdline:     (no iommu parameters)
>    cpus online: 0-23
>    iommu:       ivhd0
>    ff_rt_clk:   0
>    S0ix Entry Time: 0
>    S0ix Exit Time: 0
>    Residency Time: 0
>    suspending with +30s alarm
> 
> Nothing was written after that. The machine never resumed and needed a 
> forced power off.
> 
> So with the IOMMU enabled, every independent wake mechanism on this 
> machine has now been tried and none of them work:
> 
>    lid switch (PNP0C0D)                          no wake
>    internal keyboard (i8042, via AMD GPIO)       no wake
>    power button (ACPI fixed feature)             no wake
>    USB mouse, wakeup armed on device and hub     no wake
>    ACPI fixed-feature RTC alarm                  no wake
> 
> The last one seems the most pointed to me. The RTC alarm wakes the 
> machine through the ACPI SCI on IRQ 9, and that is exactly the path that 
> works when amd_iommu=off - pm_wakeup_irq reports 9 on every successful 
> cycle. With the IOMMU enabled the same mechanism produces nothing at 
> all, and ff_rt_clk stays at 0 across the attempt.
> 
> Still to come: the 7.3-rc4 test, and a manual walk through BIOS setup 
> looking for storage link power or D3 controls that think-lmi does not 
> export.

the bug reproduces on 7.3-rc4.

Built 7.3-rc4 from the torvalds snapshot, migrated my 6.18.51 config 
with make olddefconfig, IOMMU enabled, all 24 CPUs online, no IOMMU boot 
parameters. Same result: the machine suspends and never wakes, forced 
power off required.

Both attempts recorded by the same script, neither produced a resume block:

   === 2026-09-23T22:15:02 BEFORE
   cmdline:     (6.18.51, no iommu parameters)
   cpus online: 0-23
   iommu:       ivhd0
   ff_rt_clk:   0
   S0ix Entry Time: 0 / Exit Time: 0 / Residency Time: 0
   suspending with +30s alarm

   === 2026-09-23T22:39:06 BEFORE
   cmdline:     (7.3.0-rc4, no iommu parameters)
   cpus online: 0-23
   iommu:       ivhd0
   ff_rt_clk:   0
   S0ix Entry Time: 0 / Exit Time: 0 / Residency Time: 0
   suspending with +30s alarm

Both used a programmed RTC wakealarm at +30s and were left untouched for 
several minutes.

Relevant details of the 7.3-rc4 build, so this is not a configuration 
difference:

   CONFIG_AMD_IOMMU=y, CONFIG_IOMMU_PT=y, CONFIG_IOMMU_PT_AMDV1=y
   CONFIG_NR_CPUS=24, CONFIG_MODULES not set
   CONFIG_DEBUG_FS=y, CONFIG_PM_DEBUG=y, CONFIG_DYNAMIC_DEBUG=y
   CONFIG_AMD_MP2_STB=y, CONFIG_X86_MSR=y, CONFIG_DMIID=y
   CONFIG_LOG_BUF_SHIFT=20, CONFIG_RANDSTRUCT_NONE=y
   kernel is not tainted, builds with zero warnings

Only 243 config lines differ between my 6.18.51 and 7.3-rc4 configs. 
Both commits you pointed me at are present in 7.3-rc4: rtc-cmos uses 
platform_get_irq_optional(), and iommu/amd carries the "No ACPI device 
matched UID" check. As on 6.18, that FW_BUG message does not appear here 
either.

Two things worth noting about the 7.3 build specifically. The new IOMMU 
page table layer is in use (CONFIG_IOMMU_PT / IOMMU_PT_AMDV1 replacing 
CONFIG_IOMMU_IO_PGTABLE), so that rework does not change the outcome. 
And AMD_PMF and DRM_ACCEL_AMDXDNA are not compiled into either kernel - 
DRM_ACCEL and AMD_SFH_HID are both off in my config - so neither driver 
is involved in any of these results at all, which is a stronger 
statement than the initcall_blacklist tests I reported earlier.

Where that leaves things. With the IOMMU enabled and all 24 CPUs, on 
both 6.18.51 and 7.3-rc4:

   lid switch, internal keyboard, power button, USB mouse with wakeup
   armed, and a programmed ACPI RTC alarm        all fail to wake

   intremap=off, iommu=pt, amd_iommu_intr=legacy  all still hang
   pm_test freezer / devices / platform           all pass
   PC6 and CC6 enabled per amd-s2idle             yes

   amd_iommu=off                                  wakes normally,
                                                  Last S0i3 Status Success,
                                                  13.3s residency,
                                                  pm_wakeup_irq 9

Since it fails identically on 6.18 and 7.3 there is no working kernel 
version to bisect against. The only variable that changes the outcome is 
whether the IOMMU is enabled, and secondarily whether more than 16 CPUs 
are brought up at boot.

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

[Mario Limonciello]

On 9/23/26 15:48, Fourhundred Thecat wrote:
> the bug reproduces on 7.3-rc4.
> 
> Built 7.3-rc4 from the torvalds snapshot, migrated my 6.18.51 config 
> with make olddefconfig, IOMMU enabled, all 24 CPUs online, no IOMMU boot 
> parameters. Same result: the machine suspends and never wakes, forced 
> power off required.
> 
> Both attempts recorded by the same script, neither produced a resume block:
> 
>    === 2026-09-23T22:15:02 BEFORE
>    cmdline:     (6.18.51, no iommu parameters)
>    cpus online: 0-23
>    iommu:       ivhd0
>    ff_rt_clk:   0
>    S0ix Entry Time: 0 / Exit Time: 0 / Residency Time: 0
>    suspending with +30s alarm
> 
>    === 2026-09-23T22:39:06 BEFORE
>    cmdline:     (7.3.0-rc4, no iommu parameters)
>    cpus online: 0-23
>    iommu:       ivhd0
>    ff_rt_clk:   0
>    S0ix Entry Time: 0 / Exit Time: 0 / Residency Time: 0
>    suspending with +30s alarm
> 
> Both used a programmed RTC wakealarm at +30s and were left untouched for 
> several minutes.
> 
> Relevant details of the 7.3-rc4 build, so this is not a configuration 
> difference:
> 
>    CONFIG_AMD_IOMMU=y, CONFIG_IOMMU_PT=y, CONFIG_IOMMU_PT_AMDV1=y
>    CONFIG_NR_CPUS=24, CONFIG_MODULES not set
>    CONFIG_DEBUG_FS=y, CONFIG_PM_DEBUG=y, CONFIG_DYNAMIC_DEBUG=y
>    CONFIG_AMD_MP2_STB=y, CONFIG_X86_MSR=y, CONFIG_DMIID=y
>    CONFIG_LOG_BUF_SHIFT=20, CONFIG_RANDSTRUCT_NONE=y
>    kernel is not tainted, builds with zero warnings
> 
> Only 243 config lines differ between my 6.18.51 and 7.3-rc4 configs. 
> Both commits you pointed me at are present in 7.3-rc4: rtc-cmos uses 
> platform_get_irq_optional(), and iommu/amd carries the "No ACPI device 
> matched UID" check. As on 6.18, that FW_BUG message does not appear here 
> either.
> 
> Two things worth noting about the 7.3 build specifically. The new IOMMU 
> page table layer is in use (CONFIG_IOMMU_PT / IOMMU_PT_AMDV1 replacing 
> CONFIG_IOMMU_IO_PGTABLE), so that rework does not change the outcome. 
> And AMD_PMF and DRM_ACCEL_AMDXDNA are not compiled into either kernel - 
> DRM_ACCEL and AMD_SFH_HID are both off in my config - so neither driver 
> is involved in any of these results at all, which is a stronger 
> statement than the initcall_blacklist tests I reported earlier.
> 
> Where that leaves things. With the IOMMU enabled and all 24 CPUs, on 
> both 6.18.51 and 7.3-rc4:
> 
>    lid switch, internal keyboard, power button, USB mouse with wakeup
>    armed, and a programmed ACPI RTC alarm        all fail to wake
> 
>    intremap=off, iommu=pt, amd_iommu_intr=legacy  all still hang
>    pm_test freezer / devices / platform           all pass
>    PC6 and CC6 enabled per amd-s2idle             yes
> 
>    amd_iommu=off                                  wakes normally,
>                                                   Last S0i3 Status Success,
>                                                   13.3s residency,
>                                                   pm_wakeup_irq 9
> 
> Since it fails identically on 6.18 and 7.3 there is no working kernel 
> version to bisect against. The only variable that changes the outcome is 
> whether the IOMMU is enabled, and secondarily whether more than 16 CPUs 
> are brought up at boot.

To me this still feels like a BIOS bug.  I wouldn't discount the 
possibility that think-lmi didn't apply a setting properly or something 
like that.

Can you please try to manually go into your BIOS and reset BIOS default 
settings?  Does it reproduce with IOMMU left on?

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

[Fourhundred Thecat]

On 2026-09-23 23:10, Mario Limonciello wrote:
> On 9/23/26 15:48, Fourhundred Thecat wrote:
>> the bug reproduces on 7.3-rc4.
>>
>> Built 7.3-rc4 from the torvalds snapshot, migrated my 6.18.51 config 
>> with make olddefconfig, IOMMU enabled, all 24 CPUs online, no IOMMU 
>> boot parameters. Same result: the machine suspends and never wakes, 
>> forced power off required.
>>
>> Both attempts recorded by the same script, neither produced a resume 
>> block:
>>
>>    === 2026-09-23T22:15:02 BEFORE
>>    cmdline:     (6.18.51, no iommu parameters)
>>    cpus online: 0-23
>>    iommu:       ivhd0
>>    ff_rt_clk:   0
>>    S0ix Entry Time: 0 / Exit Time: 0 / Residency Time: 0
>>    suspending with +30s alarm
>>
>>    === 2026-09-23T22:39:06 BEFORE
>>    cmdline:     (7.3.0-rc4, no iommu parameters)
>>    cpus online: 0-23
>>    iommu:       ivhd0
>>    ff_rt_clk:   0
>>    S0ix Entry Time: 0 / Exit Time: 0 / Residency Time: 0
>>    suspending with +30s alarm
>>
>> Both used a programmed RTC wakealarm at +30s and were left untouched 
>> for several minutes.
>>
>> Relevant details of the 7.3-rc4 build, so this is not a configuration 
>> difference:
>>
>>    CONFIG_AMD_IOMMU=y, CONFIG_IOMMU_PT=y, CONFIG_IOMMU_PT_AMDV1=y
>>    CONFIG_NR_CPUS=24, CONFIG_MODULES not set
>>    CONFIG_DEBUG_FS=y, CONFIG_PM_DEBUG=y, CONFIG_DYNAMIC_DEBUG=y
>>    CONFIG_AMD_MP2_STB=y, CONFIG_X86_MSR=y, CONFIG_DMIID=y
>>    CONFIG_LOG_BUF_SHIFT=20, CONFIG_RANDSTRUCT_NONE=y
>>    kernel is not tainted, builds with zero warnings
>>
>> Only 243 config lines differ between my 6.18.51 and 7.3-rc4 configs. 
>> Both commits you pointed me at are present in 7.3-rc4: rtc-cmos uses 
>> platform_get_irq_optional(), and iommu/amd carries the "No ACPI device 
>> matched UID" check. As on 6.18, that FW_BUG message does not appear 
>> here either.
>>
>> Two things worth noting about the 7.3 build specifically. The new 
>> IOMMU page table layer is in use (CONFIG_IOMMU_PT / IOMMU_PT_AMDV1 
>> replacing CONFIG_IOMMU_IO_PGTABLE), so that rework does not change the 
>> outcome. And AMD_PMF and DRM_ACCEL_AMDXDNA are not compiled into 
>> either kernel - DRM_ACCEL and AMD_SFH_HID are both off in my config - 
>> so neither driver is involved in any of these results at all, which is 
>> a stronger statement than the initcall_blacklist tests I reported 
>> earlier.
>>
>> Where that leaves things. With the IOMMU enabled and all 24 CPUs, on 
>> both 6.18.51 and 7.3-rc4:
>>
>>    lid switch, internal keyboard, power button, USB mouse with wakeup
>>    armed, and a programmed ACPI RTC alarm        all fail to wake
>>
>>    intremap=off, iommu=pt, amd_iommu_intr=legacy  all still hang
>>    pm_test freezer / devices / platform           all pass
>>    PC6 and CC6 enabled per amd-s2idle             yes
>>
>>    amd_iommu=off                                  wakes normally,
>>                                                   Last S0i3 Status 
>> Success,
>>                                                   13.3s residency,
>>                                                   pm_wakeup_irq 9
>>
>> Since it fails identically on 6.18 and 7.3 there is no working kernel 
>> version to bisect against. The only variable that changes the outcome 
>> is whether the IOMMU is enabled, and secondarily whether more than 16 
>> CPUs are brought up at boot.
> 
> To me this still feels like a BIOS bug.  I wouldn't discount the 
> possibility that think-lmi didn't apply a setting properly or something 
> like that.
> 
> Can you please try to manually go into your BIOS and reset BIOS default 
> settings?  Does it reproduce with IOMMU left on?

I did another test:

I bootet latest Debian live CD image before touching the BIOS, and it 
reproduces.

Debian live, kernel 7.1.12+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
7.1.12-1 (2026-08-28). Stock distro kernel with modules, systemd and 
udev, every device driver bound, distro defaults throughout, nothing of 
mine involved except the BIOS settings. echo mem > /sys/power/state 
suspends and never wakes. Forced power off required, same as always.

So my custom kernel configuration is not the cause.

That now leaves three kernels reproducing it:

   6.18.51    my build, minimal config
   7.3-rc4    my build, migrated config
   7.1.12     stock Debian live image, distro config

I will do the BIOS defaults reset next, as you asked.

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

[Fourhundred Thecat]

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.

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

thank you for your help !

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

[Mario Limonciello]

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.

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

[Fourhundred Thecat]

On 2026-09-25 15:30, Mario Limonciello wrote:
> 
> 
> 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.

Captured acpidumps for all three configurations. Your hunch was right 
that the IVRS table is still created with AmdVt disabled, but it is not 
identical - and the difference looks like the actual mechanism.

Summary, all with the IOMMU enabled and 24 CPUs online:

   config          IVinfo      IVRS len   IVMDs   MSFT0201 in IVRS 
MSFT0201 ACPI dev   SSDTs
   both enabled    0x00203043  0x216      3       yes                yes 
                 29
   AmdVt off       0x00203041  0x1F6      2       yes                yes 
                 29
   Pluton off      0x00203043  0x216      3       yes                NO 
                 28

AmdVt off changes two things. The IVinfo word loses bit 0x2, the 
DmaRemap bit you already parse at offset 36. And the table is 32 bytes 
shorter because one IVMD disappears:

   both enabled:
     IVMD DeviceId=0060 Flags=07 Start=0x7D900000 Len=0x100000
     IVMD DeviceId=C507 Flags=08 Start=0x6B400000 Len=0x20000
     IVMD DeviceId=C100 Flags=08 Start=0x6B1F5000 Len=0x28000

   AmdVt off:
     IVMD DeviceId=C507 Flags=08 Start=0x6B400000 Len=0x20000
     IVMD DeviceId=C100 Flags=08 Start=0x6B1F5000 Len=0x28000

DeviceId 0x0060 is MSFT0201:

   AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60

and Flags 0x07 is unity mapped with read and write. So disabling AMD 
virtualization removes Pluton's unity mapped DMA region from IVRS, while 
the device is still declared in IVRS, still present as an ACPI device, 
and still attached to iommu group 0:

   platform MSFT0201:00: Adding to iommu group 0

That would leave Pluton's DMA translated with nothing mapped for it, 
which fits every observation: it only breaks with the IOMMU enabled, 
amd_iommu=off is the only thing that fixes it, and neither intremap=off 
nor iommu=pt helps, since iommu=pt gives other devices identity domains 
but the IVMD is how firmware asks for one for this device specifically.

Pluton off is a different failure. The IVRS is byte identical to the 
working case, IVMD 0060 included, but one SSDT is gone and with it the 
MSFT0201 ACPI device. Your existing check already catches that case 
correctly:

   found_iommu=True  found_acpi=False
   -> IOMMU is misconfigured: missing MSFT0201 ACPI device

The AmdVt case is the one that slips through. In check_iommu():

   if not found_ivrs_dmar and not found_ivrs_msft0201:

with AmdVt off, found_ivrs_dmar is False because bit 0x2 is cleared, but 
found_ivrs_msft0201 is True, so the and makes it pass and the tool 
reports "IOMMU properly configured" on a machine that cannot be woken.

So to answer your question about keying off something else: yes, and I 
think the signal is "IVRS declares an ACPI HID device but provides no 
IVMD covering its device id". That needs no vendor attributes and no DMI 
matching. The device id sits 3 bytes before the HID string in the type 
0xF0 entry, and IVMDs are subtable types 0x20/0x21/0x22 with the device 
id at entry offset 4:

   devid = struct.unpack_from("<H", data, data.find(b"MSFT0201") - 3)[0]
   off = 48
   while off + 4 <= len(data):
       length = struct.unpack_from("<H", data, off + 2)[0]
       if length == 0:
           break
       if data[off] in (0x20, 0x21, 0x22):
           if struct.unpack_from("<H", data, off + 4)[0] == devid:
               mapped = True
               break
       off += length

I checked this against all three dumps: it reports mapped for 
both-enabled and Pluton-off, and unmapped for AmdVt-off. Note that it 
would contradict test_check_iommu_no_dma_protection_BUT_msft0201, which 
currently asserts that MSFT0201 in IVRS is an acceptable substitute for 
pre-boot DMA protection, so whether to change that semantic is your call.

I am happy to send you the three acpidumps, with the extracted and 
disassembled tables and a record of the BIOS settings each was taken under.

Beyond that I have to stop here. This has taken the better part of a 
week, a lot of forced power cycles, and around $700 in LLM tokens 
working through it, and I am out of time and energy to take it further. 
The machine works now with AMD virtualization and Pluton enabled, which 
is a perfectly acceptable outcome for me.

Everything I found is in this thread, and I hope the IVRS observation is 
useful to you or to whoever picks it up. Thanks for the help getting 
here - the amd-s2idle tool, the pointer to e9f850ba66cd, and the 
suggestion to reset the BIOS were all what moved it forward.

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

[Mario Limonciello]

> Captured acpidumps for all three configurations. Your hunch was right 
> that the IVRS table is still created with AmdVt disabled, but it is not 
> identical - and the difference looks like the actual mechanism.

OK.  That makes a lot of sense for this issue now.

> 
> Summary, all with the IOMMU enabled and 24 CPUs online:
> 
>    config          IVinfo      IVRS len   IVMDs   MSFT0201 in IVRS 
> MSFT0201 ACPI dev   SSDTs
>    both enabled    0x00203043  0x216      3       yes                yes 
>                  29
>    AmdVt off       0x00203041  0x1F6      2       yes                yes 
>                  29
>    Pluton off      0x00203043  0x216      3       yes                NO 
>                  28
> 
> AmdVt off changes two things. The IVinfo word loses bit 0x2, the 
> DmaRemap bit you already parse at offset 36. And the table is 32 bytes 
> shorter because one IVMD disappears:
> 
>    both enabled:
>      IVMD DeviceId=0060 Flags=07 Start=0x7D900000 Len=0x100000
>      IVMD DeviceId=C507 Flags=08 Start=0x6B400000 Len=0x20000
>      IVMD DeviceId=C100 Flags=08 Start=0x6B1F5000 Len=0x28000
> 
>    AmdVt off:
>      IVMD DeviceId=C507 Flags=08 Start=0x6B400000 Len=0x20000
>      IVMD DeviceId=C100 Flags=08 Start=0x6B1F5000 Len=0x28000
> 
> DeviceId 0x0060 is MSFT0201:
> 
>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
> 
> and Flags 0x07 is unity mapped with read and write. So disabling AMD 
> virtualization removes Pluton's unity mapped DMA region from IVRS, while 
> the device is still declared in IVRS, still present as an ACPI device, 
> and still attached to iommu group 0:
> 
>    platform MSFT0201:00: Adding to iommu group 0
> 
> That would leave Pluton's DMA translated with nothing mapped for it, 
> which fits every observation: it only breaks with the IOMMU enabled, 
> amd_iommu=off is the only thing that fixes it, and neither intremap=off 
> nor iommu=pt helps, since iommu=pt gives other devices identity domains 
> but the IVMD is how firmware asks for one for this device specifically.
> 
> Pluton off is a different failure. The IVRS is byte identical to the 
> working case, IVMD 0060 included, but one SSDT is gone and with it the 
> MSFT0201 ACPI device. Your existing check already catches that case 
> correctly:
> 
>    found_iommu=True  found_acpi=False
>    -> IOMMU is misconfigured: missing MSFT0201 ACPI device
> 
> The AmdVt case is the one that slips through. In check_iommu():
> 
>    if not found_ivrs_dmar and not found_ivrs_msft0201:
> 
> with AmdVt off, found_ivrs_dmar is False because bit 0x2 is cleared, but 
> found_ivrs_msft0201 is True, so the and makes it pass and the tool 
> reports "IOMMU properly configured" on a machine that cannot be woken.
> 
> So to answer your question about keying off something else: yes, and I 
> think the signal is "IVRS declares an ACPI HID device but provides no 
> IVMD covering its device id". That needs no vendor attributes and no DMI 
> matching. The device id sits 3 bytes before the HID string in the type 
> 0xF0 entry, and IVMDs are subtable types 0x20/0x21/0x22 with the device 
> id at entry offset 4:
> 
>    devid = struct.unpack_from("<H", data, data.find(b"MSFT0201") - 3)[0]
>    off = 48
>    while off + 4 <= len(data):
>        length = struct.unpack_from("<H", data, off + 2)[0]
>        if length == 0:
>            break
>        if data[off] in (0x20, 0x21, 0x22):
>            if struct.unpack_from("<H", data, off + 4)[0] == devid:
>                mapped = True
>                break
>        off += length
> 
> I checked this against all three dumps: it reports mapped for both- 
> enabled and Pluton-off, and unmapped for AmdVt-off. Note that it would 
> contradict test_check_iommu_no_dma_protection_BUT_msft0201, which 
> currently asserts that MSFT0201 in IVRS is an acceptable substitute for 
> pre-boot DMA protection, so whether to change that semantic is your call.
> 
> I am happy to send you the three acpidumps, with the extracted and 
> disassembled tables and a record of the BIOS settings each was taken under.
> 
> Beyond that I have to stop here. This has taken the better part of a 
> week, a lot of forced power cycles, and around $700 in LLM tokens 
> working through it, and I am out of time and energy to take it further. 
> The machine works now with AMD virtualization and Pluton enabled, which 
> is a perfectly acceptable outcome for me.
> 
> Everything I found is in this thread, and I hope the IVRS observation is 
> useful to you or to whoever picks it up. Thanks for the help getting 
> here - the amd-s2idle tool, the pointer to e9f850ba66cd, and the 
> suggestion to reset the BIOS were all what moved it forward.
> 
> 
I've opened up a PR that should hopefully adjust the tool against your 
failure cases.  Would you be able to confirm this against your system?

https://github.com/superm1/amd-debug-tools/pull/58

If it doesn't work, can you please send me the acpidumps and I'll adjust.

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

[Fourhundred Thecat]

[-- Attachment #1: Type: text/plain, Size: 5700 bytes --]

On 2026-09-26 20:29, Mario Limonciello wrote:
>> Captured acpidumps for all three configurations. Your hunch was right 
>> that the IVRS table is still created with AmdVt disabled, but it is 
>> not identical - and the difference looks like the actual mechanism.
> 
> OK.  That makes a lot of sense for this issue now.
> 
>>
>> Summary, all with the IOMMU enabled and 24 CPUs online:
>>
>>    config          IVinfo      IVRS len   IVMDs   MSFT0201 in IVRS 
>> MSFT0201 ACPI dev   SSDTs
>>    both enabled    0x00203043  0x216      3       yes                
>> yes                  29
>>    AmdVt off       0x00203041  0x1F6      2       yes                
>> yes                  29
>>    Pluton off      0x00203043  0x216      3       yes                
>> NO                  28
>>
>> AmdVt off changes two things. The IVinfo word loses bit 0x2, the 
>> DmaRemap bit you already parse at offset 36. And the table is 32 bytes 
>> shorter because one IVMD disappears:
>>
>>    both enabled:
>>      IVMD DeviceId=0060 Flags=07 Start=0x7D900000 Len=0x100000
>>      IVMD DeviceId=C507 Flags=08 Start=0x6B400000 Len=0x20000
>>      IVMD DeviceId=C100 Flags=08 Start=0x6B1F5000 Len=0x28000
>>
>>    AmdVt off:
>>      IVMD DeviceId=C507 Flags=08 Start=0x6B400000 Len=0x20000
>>      IVMD DeviceId=C100 Flags=08 Start=0x6B1F5000 Len=0x28000
>>
>> DeviceId 0x0060 is MSFT0201:
>>
>>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
>>
>> and Flags 0x07 is unity mapped with read and write. So disabling AMD 
>> virtualization removes Pluton's unity mapped DMA region from IVRS, 
>> while the device is still declared in IVRS, still present as an ACPI 
>> device, and still attached to iommu group 0:
>>
>>    platform MSFT0201:00: Adding to iommu group 0
>>
>> That would leave Pluton's DMA translated with nothing mapped for it, 
>> which fits every observation: it only breaks with the IOMMU enabled, 
>> amd_iommu=off is the only thing that fixes it, and neither 
>> intremap=off nor iommu=pt helps, since iommu=pt gives other devices 
>> identity domains but the IVMD is how firmware asks for one for this 
>> device specifically.
>>
>> Pluton off is a different failure. The IVRS is byte identical to the 
>> working case, IVMD 0060 included, but one SSDT is gone and with it the 
>> MSFT0201 ACPI device. Your existing check already catches that case 
>> correctly:
>>
>>    found_iommu=True  found_acpi=False
>>    -> IOMMU is misconfigured: missing MSFT0201 ACPI device
>>
>> The AmdVt case is the one that slips through. In check_iommu():
>>
>>    if not found_ivrs_dmar and not found_ivrs_msft0201:
>>
>> with AmdVt off, found_ivrs_dmar is False because bit 0x2 is cleared, 
>> but found_ivrs_msft0201 is True, so the and makes it pass and the tool 
>> reports "IOMMU properly configured" on a machine that cannot be woken.
>>
>> So to answer your question about keying off something else: yes, and I 
>> think the signal is "IVRS declares an ACPI HID device but provides no 
>> IVMD covering its device id". That needs no vendor attributes and no 
>> DMI matching. The device id sits 3 bytes before the HID string in the 
>> type 0xF0 entry, and IVMDs are subtable types 0x20/0x21/0x22 with the 
>> device id at entry offset 4:
>>
>>    devid = struct.unpack_from("<H", data, data.find(b"MSFT0201") - 3)[0]
>>    off = 48
>>    while off + 4 <= len(data):
>>        length = struct.unpack_from("<H", data, off + 2)[0]
>>        if length == 0:
>>            break
>>        if data[off] in (0x20, 0x21, 0x22):
>>            if struct.unpack_from("<H", data, off + 4)[0] == devid:
>>                mapped = True
>>                break
>>        off += length
>>
>> I checked this against all three dumps: it reports mapped for both- 
>> enabled and Pluton-off, and unmapped for AmdVt-off. Note that it would 
>> contradict test_check_iommu_no_dma_protection_BUT_msft0201, which 
>> currently asserts that MSFT0201 in IVRS is an acceptable substitute 
>> for pre-boot DMA protection, so whether to change that semantic is 
>> your call.
>>
>> I am happy to send you the three acpidumps, with the extracted and 
>> disassembled tables and a record of the BIOS settings each was taken 
>> under.
>>
>> Beyond that I have to stop here. This has taken the better part of a 
>> week, a lot of forced power cycles, and around $700 in LLM tokens 
>> working through it, and I am out of time and energy to take it 
>> further. The machine works now with AMD virtualization and Pluton 
>> enabled, which is a perfectly acceptable outcome for me.
>>
>> Everything I found is in this thread, and I hope the IVRS observation 
>> is useful to you or to whoever picks it up. Thanks for the help 
>> getting here - the amd-s2idle tool, the pointer to e9f850ba66cd, and 
>> the suggestion to reset the BIOS were all what moved it forward.
>>
>>
> I've opened up a PR that should hopefully adjust the tool against your 
> failure cases.  Would you be able to confirm this against your system?

I am not able to test anything anymore. I have erased the debugging 
setup that I had on my laptop, and reinstalled it clean. I no longer 
have the claude history and the debugging tools. And I cannot do it 
without claude (nothing we did made any sense to me)

> https://github.com/superm1/amd-debug-tools/pull/58
> 
> If it doesn't work, can you please send me the acpidumps and I'll adjust.

but hopefully you can make sense of the attached  acpidumps

thank you,

[-- Attachment #2: ivrs-only.tar.xz --]
[-- Type: application/x-xz, Size: 2876 bytes --]

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

[Fourhundred Thecat]

On 2026-09-29 07:43, Fourhundred Thecat wrote:
> On 2026-09-26 20:29, Mario Limonciello wrote:
>>> Captured acpidumps for all three configurations. Your hunch was right 
>>> that the IVRS table is still created with AmdVt disabled, but it is 
>>> not identical - and the difference looks like the actual mechanism.
>>
>> OK.  That makes a lot of sense for this issue now.
>>
>>>
>>> Summary, all with the IOMMU enabled and 24 CPUs online:
>>>
>>>    config          IVinfo      IVRS len   IVMDs   MSFT0201 in IVRS 
>>> MSFT0201 ACPI dev   SSDTs
>>>    both enabled    0x00203043  0x216      3       yes yes 
>>>                  29
>>>    AmdVt off       0x00203041  0x1F6      2       yes yes 
>>>                  29
>>>    Pluton off      0x00203043  0x216      3       yes NO 
>>>                  28
>>>
>>> AmdVt off changes two things. The IVinfo word loses bit 0x2, the 
>>> DmaRemap bit you already parse at offset 36. And the table is 32 
>>> bytes shorter because one IVMD disappears:
>>>
>>>    both enabled:
>>>      IVMD DeviceId=0060 Flags=07 Start=0x7D900000 Len=0x100000
>>>      IVMD DeviceId=C507 Flags=08 Start=0x6B400000 Len=0x20000
>>>      IVMD DeviceId=C100 Flags=08 Start=0x6B1F5000 Len=0x28000
>>>
>>>    AmdVt off:
>>>      IVMD DeviceId=C507 Flags=08 Start=0x6B400000 Len=0x20000
>>>      IVMD DeviceId=C100 Flags=08 Start=0x6B1F5000 Len=0x28000
>>>
>>> DeviceId 0x0060 is MSFT0201:
>>>
>>>    AMD-Vi: ivrs, add hid:MSFT0201, uid:1, rdevid:0x60
>>>
>>> and Flags 0x07 is unity mapped with read and write. So disabling AMD 
>>> virtualization removes Pluton's unity mapped DMA region from IVRS, 
>>> while the device is still declared in IVRS, still present as an ACPI 
>>> device, and still attached to iommu group 0:
>>>
>>>    platform MSFT0201:00: Adding to iommu group 0
>>>
>>> That would leave Pluton's DMA translated with nothing mapped for it, 
>>> which fits every observation: it only breaks with the IOMMU enabled, 
>>> amd_iommu=off is the only thing that fixes it, and neither 
>>> intremap=off nor iommu=pt helps, since iommu=pt gives other devices 
>>> identity domains but the IVMD is how firmware asks for one for this 
>>> device specifically.
>>>
>>> Pluton off is a different failure. The IVRS is byte identical to the 
>>> working case, IVMD 0060 included, but one SSDT is gone and with it 
>>> the MSFT0201 ACPI device. Your existing check already catches that 
>>> case correctly:
>>>
>>>    found_iommu=True  found_acpi=False
>>>    -> IOMMU is misconfigured: missing MSFT0201 ACPI device
>>>
>>> The AmdVt case is the one that slips through. In check_iommu():
>>>
>>>    if not found_ivrs_dmar and not found_ivrs_msft0201:
>>>
>>> with AmdVt off, found_ivrs_dmar is False because bit 0x2 is cleared, 
>>> but found_ivrs_msft0201 is True, so the and makes it pass and the 
>>> tool reports "IOMMU properly configured" on a machine that cannot be 
>>> woken.
>>>
>>> So to answer your question about keying off something else: yes, and 
>>> I think the signal is "IVRS declares an ACPI HID device but provides 
>>> no IVMD covering its device id". That needs no vendor attributes and 
>>> no DMI matching. The device id sits 3 bytes before the HID string in 
>>> the type 0xF0 entry, and IVMDs are subtable types 0x20/0x21/0x22 with 
>>> the device id at entry offset 4:
>>>
>>>    devid = struct.unpack_from("<H", data, data.find(b"MSFT0201") - 3)[0]
>>>    off = 48
>>>    while off + 4 <= len(data):
>>>        length = struct.unpack_from("<H", data, off + 2)[0]
>>>        if length == 0:
>>>            break
>>>        if data[off] in (0x20, 0x21, 0x22):
>>>            if struct.unpack_from("<H", data, off + 4)[0] == devid:
>>>                mapped = True
>>>                break
>>>        off += length
>>>
>>> I checked this against all three dumps: it reports mapped for both- 
>>> enabled and Pluton-off, and unmapped for AmdVt-off. Note that it 
>>> would contradict test_check_iommu_no_dma_protection_BUT_msft0201, 
>>> which currently asserts that MSFT0201 in IVRS is an acceptable 
>>> substitute for pre-boot DMA protection, so whether to change that 
>>> semantic is your call.
>>>
>>> I am happy to send you the three acpidumps, with the extracted and 
>>> disassembled tables and a record of the BIOS settings each was taken 
>>> under.
>>>
>>> Beyond that I have to stop here. This has taken the better part of a 
>>> week, a lot of forced power cycles, and around $700 in LLM tokens 
>>> working through it, and I am out of time and energy to take it 
>>> further. The machine works now with AMD virtualization and Pluton 
>>> enabled, which is a perfectly acceptable outcome for me.
>>>
>>> Everything I found is in this thread, and I hope the IVRS observation 
>>> is useful to you or to whoever picks it up. Thanks for the help 
>>> getting here - the amd-s2idle tool, the pointer to e9f850ba66cd, and 
>>> the suggestion to reset the BIOS were all what moved it forward.
>>>
>>>
>> I've opened up a PR that should hopefully adjust the tool against your 
>> failure cases.  Would you be able to confirm this against your system?
> 
> I am not able to test anything anymore. I have erased the debugging 
> setup that I had on my laptop, and reinstalled it clean. I no longer 
> have the claude history and the debugging tools. And I cannot do it 
> without claude (nothing we did made any sense to me)
> 
>> https://github.com/superm1/amd-debug-tools/pull/58
>>
>> If it doesn't work, can you please send me the acpidumps and I'll adjust.
> 
> but hopefully you can make sense of the attached  acpidumps
> 
> thank you,

looks like my previous email bounced because .tar.xz attachment
so I have uploaded the file here:

https://www.swisstransfer.com/dl/01a0ebbb-a094-725c-b9f1-8a8ba0d1da11

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

[Mario Limonciello]

> > I am not able to test anything anymore. I have erased the debugging
> > setup that I had on my laptop, and reinstalled it clean. I no longer
> > have the claude history and the debugging tools. And I cannot do it
> > without claude (nothing we did made any sense to me)
> >
> >> https://github.com/superm1/amd-debug-tools/pull/58
> >>
> >> If it doesn't work, can you please send me the acpidumps and I'll adjust.
> >
> > but hopefully you can make sense of the attached  acpidumps
> >
> > thank you,
>
> looks like my previous email bounced because .tar.xz attachment
> so I have uploaded the file here:
>
> https://www.swisstransfer.com/dl/01a0ebbb-a094-725c-b9f1-8a8ba0d1da11

OK.  Those seem to parse as I would expect.