On 9/3/25 12:13 PM, aprilgrimoire wrote:
Hi,
Can you please reproduce the issue using 'amd-s2idle' from
https://pypi.org/project/amd-debug-tools/ ?
Basically install the wheel, run 'amd-s2idle test'. When prompted how
long, set it for ~20 seconds. Then wait for the LED to flash and close
the lid and it should wake up and generate a report.
This will capture a lot of artifacts about the problem in the report and
we can go from there on next steps. Ideally if you can put the report
on a new issue here and tag me (@superm1):
https://gitlab.freedesktop.org/drm/amd/-/issues
We can iterate back and forth on it to come up with the best solution.
Thanks,
Hi! Here's the output:
https://paste.gentoo.zip/mpV8dQcl
I disabled the patched dsdt since with it amd-s2idle would think ASPM Policy is set to power-saving and refuse to run.
It's late here and I'll probably return tomorrow. Thanks!
IRQ1 doesn't show up in this report, so this is not a problem with the
keyboard wakeup.
There's a few things that stand out to me.
1) There are ACPI errors with the PEP _DSM; specificially the screen on
action. This isn't likely the cause of this issue but it's most
definitely a BIOS bug.
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.ACDC.RTAC],
AE_NOT_FOUND (20250404/psargs-332)
ACPI Error: Aborting method \_SB.PEP._DSM due to previous error
(AE_NOT_FOUND) (20250404/psparse-529)
ACPI: \_SB_.PEP_: Failed to transitioned to state screen on
2) The wakeup is from IRQ 7 (like you said) which is the GPIO controller.
PM: Triggering wakeup from IRQ 7
Woke up from IRQ 7 (IR-IO-APIC 7-fasteoi pinctrl_amd)
The GPIO controller wakes up the system when any of the pins that are
marked as wake pins are triggered. In your case this is GPIO 0.
GPIO 0 is active: 0x38157800
According to the SSDT _EVT handler this notifies the _PWRB ACPI object.
Case (Zero)
{
M000 (0x3900)
Notify (\_SB.PWRB, 0x80) // Status Change
}
We can see that notify happened here:
Dispatching Notify on [PWRB] (Device) Value 0x80 (Status Change)
So based on above what it looks like is going on to me is that the lid
is likely indirectly tied to GPIO 0 in this design. It's not clear if
it's a mux, directly connected or if the EC drives that GPIO or what not.
It's worth noting that we did have a Linux kernel change to turn off
debounce for all GPIOs recently at suspend time [1]. You can see in
your log this message associated with it.
Clearing debounce for GPIO #0 during suspend.
I don't expect it's the cause of your issue, but you could try to revert
it to confirm.
Instead I think what's going on is that they have their design expecting
that Windows does a "dark screen wakeup". This is where it exits a
hardware sleep state but doesn't fully wake the system. If no input
activity happens then it goes back to hardware sleep.
This is something that common userspace (systemd on most systems)
doesn't support today.
One option for you is to try to set this GPIO not to be a wake source by
gpiolib_acpi.ignore_wake=AMDI0030:00@0.
If this helps, please also check whether this breaks power button wakeup
though. If it does we might be trading one wakeup source for another if
they're muxed.
[1]
https://github.com/torvalds/linux/commit/8ff4fb276e2384a87ae7f65f3c28e1e139dbb3fe
