[REGRESSION] pinctrl-amd: Don't clear S4 wake bits at probe causes power off to reboot AMD Ryzen laptop

[REGRESSION] pinctrl-amd: Don't clear S4 wake bits at probe causes power off to reboot AMD Ryzen laptop

[Olzhas]

Hi Mario,

I am experiencing a regression on my laptop where attempting to power
off the machine results in an immediate reboot instead of a shutdown.

The last known good kernel is v7.1.7, while v7.1.8 is the first known
bad release.

I bisected the regression across 9 kernel builds and identified the
following commit as the first bad commit:

a7c855969b1a ("pinctrl-amd: Don't clear S4 wake bits at probe")

With this commit present, running:

    systemctl poweroff

causes the laptop to power off and then immediately power back on.

I reverted this specific commit on top of v7.3.0-rc3 and the issue is
completely resolved. The laptop now powers off correctly and remains
off.

Hardware:
- Laptop: Chuwi CoreBook Plus 16
- DMI board vendor: Default string
- DMI board name: Default string
- DMI BIOS version: AB8139_S_2C_V00.01_007
- DMI BIOS date: 2025-08-05
- CPU reported by the system: AMD Ryzen 5 7430U with Radeon Graphics
- The CPU/hardware appears to correspond to Ryzen 5 5500U / Lucienne
  silicon, although I am not certain whether this is relevant.

Software:
- Distribution: Arch Linux
- Last known good: v7.1.7
- First known bad: v7.1.8
- Current test kernel: v7.3.0-rc3 with a7c855969b1a reverted

I have verified the fix by booting the reverted kernel and testing
poweroff successfully.

Since the DMI board strings are generic ("Default string"), I would be
happy to provide an ACPI dump, dmesg output, kernel configuration,
bisect log, or perform additional testing if needed.

I suspect this may be related to an S4 wake source left enabled by the
firmware, but I have not identified the exact wake source yet.

Best regards,
Olzhas Marat

#regzbot introduced: a7c855969b1a

Re: [REGRESSION] pinctrl-amd: Don't clear S4 wake bits at probe causes power off to reboot AMD Ryzen laptop

[Mario Limonciello]

On 9/20/26 12:00 PM, Olzhas wrote:
> Hi Mario,
> 
> I am experiencing a regression on my laptop where attempting to power
> off the machine results in an immediate reboot instead of a shutdown.
> 
> The last known good kernel is v7.1.7, while v7.1.8 is the first known
> bad release.
> 
> I bisected the regression across 9 kernel builds and identified the
> following commit as the first bad commit:
> 
> a7c855969b1a ("pinctrl-amd: Don't clear S4 wake bits at probe")
> 
> With this commit present, running:
> 
>      systemctl poweroff
> 
> causes the laptop to power off and then immediately power back on.
> 
> I reverted this specific commit on top of v7.3.0-rc3 and the issue is
> completely resolved. The laptop now powers off correctly and remains
> off.
> 
> Hardware:
> - Laptop: Chuwi CoreBook Plus 16
> - DMI board vendor: Default string
> - DMI board name: Default string
> - DMI BIOS version: AB8139_S_2C_V00.01_007
> - DMI BIOS date: 2025-08-05
> - CPU reported by the system: AMD Ryzen 5 7430U with Radeon Graphics
> - The CPU/hardware appears to correspond to Ryzen 5 5500U / Lucienne
>    silicon, although I am not certain whether this is relevant.
> 
> Software:
> - Distribution: Arch Linux
> - Last known good: v7.1.7
> - First known bad: v7.1.8
> - Current test kernel: v7.3.0-rc3 with a7c855969b1a reverted
> 
> I have verified the fix by booting the reverted kernel and testing
> poweroff successfully.
> 
> Since the DMI board strings are generic ("Default string"), I would be
> happy to provide an ACPI dump, dmesg output, kernel configuration,
> bisect log, or perform additional testing if needed.
> 
> I suspect this may be related to an S4 wake source left enabled by the
> firmware, but I have not identified the exact wake source yet.
> 
> Best regards,
> Olzhas Marat
> 
> #regzbot introduced: a7c855969b1a
> 

This is most likely a BIOS bug, but we need to dig into the details to 
understand more and decide what to do.  It could also be a driver bug, 
most likely in a WLAN driver.

Can you please open a kernel bugzilla with the following information:

1) /sys/kernel/debug/gpio without the commit
2) /sys/kernel/debug/gpio with the commit
3) acpidump (just once)
4) amd-s2idle report (this will capture and associate some information 
that will make this easier to triage)

Please CC me into the bug report.

Thanks

Re: [REGRESSION] pinctrl-amd: Don't clear S4 wake bits at probe causes power off to reboot AMD Ryzen laptop

[Mario Limonciello]

On 9/20/26 12:05, Mario Limonciello wrote:
> 
> 
> On 9/20/26 12:00 PM, Olzhas wrote:
>> Hi Mario,
>>
>> I am experiencing a regression on my laptop where attempting to power
>> off the machine results in an immediate reboot instead of a shutdown.
>>
>> The last known good kernel is v7.1.7, while v7.1.8 is the first known
>> bad release.
>>
>> I bisected the regression across 9 kernel builds and identified the
>> following commit as the first bad commit:
>>
>> a7c855969b1a ("pinctrl-amd: Don't clear S4 wake bits at probe")
>>
>> With this commit present, running:
>>
>>      systemctl poweroff
>>
>> causes the laptop to power off and then immediately power back on.
>>
>> I reverted this specific commit on top of v7.3.0-rc3 and the issue is
>> completely resolved. The laptop now powers off correctly and remains
>> off.
>>
>> Hardware:
>> - Laptop: Chuwi CoreBook Plus 16
>> - DMI board vendor: Default string
>> - DMI board name: Default string
>> - DMI BIOS version: AB8139_S_2C_V00.01_007
>> - DMI BIOS date: 2025-08-05
>> - CPU reported by the system: AMD Ryzen 5 7430U with Radeon Graphics
>> - The CPU/hardware appears to correspond to Ryzen 5 5500U / Lucienne
>>    silicon, although I am not certain whether this is relevant.
>>
>> Software:
>> - Distribution: Arch Linux
>> - Last known good: v7.1.7
>> - First known bad: v7.1.8
>> - Current test kernel: v7.3.0-rc3 with a7c855969b1a reverted
>>
>> I have verified the fix by booting the reverted kernel and testing
>> poweroff successfully.
>>
>> Since the DMI board strings are generic ("Default string"), I would be
>> happy to provide an ACPI dump, dmesg output, kernel configuration,
>> bisect log, or perform additional testing if needed.
>>
>> I suspect this may be related to an S4 wake source left enabled by the
>> firmware, but I have not identified the exact wake source yet.
>>
>> Best regards,
>> Olzhas Marat
>>
>> #regzbot introduced: a7c855969b1a
>>
> 
> This is most likely a BIOS bug, but we need to dig into the details to 
> understand more and decide what to do.  It could also be a driver bug, 
> most likely in a WLAN driver.
> 
> Can you please open a kernel bugzilla with the following information:
> 
> 1) /sys/kernel/debug/gpio without the commit
> 2) /sys/kernel/debug/gpio with the commit
> 3) acpidump (just once)
> 4) amd-s2idle report (this will capture and associate some information 
> that will make this easier to triage)
> 
> Please CC me into the bug report.
> 
> Thanks

FYI for others, a bug report is opened here:

https://bugzilla.kernel.org/show_bug.cgi?id=222041

We are working on narrowing down which GPIO is causing problems for this 
machine and then will decide what to do.