Bug 218829
| Summary: | B650M/Ryzen 7700X PC immediately wakes up from "deep" suspend | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | CUI Hao (cuihao.leo) |
| Component: | Power-Sleep-Wake | Assignee: | acpi_power-sleep-wake |
| Status: | RESOLVED DOCUMENTED | ||
| Severity: | normal | CC: | eugene.moskalenko, mario.limonciello |
| Priority: | P3 | ||
| Hardware: | AMD | ||
| OS: | Linux | ||
| Kernel Version: | 6.8.9 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
acpidump
dmesg dsdt.dsl |
||
|
Description
CUI Hao
2024-05-12 23:52:01 UTC
Created attachment 306288 [details]
dmesg
Found this https://lore.kernel.org/all/20221012221028.4817-1-mario.limonciello@amd.com/T/ Setting gpiolib_acpi.ignore_interrupt=AMDI0030:00@3 fixes the issue. Though I still wonder what GPIO 3 does and if there is any caveat of this workaround. I can't seem to decompile your DSDT. $ iasl -d dsdt.dat Intel ACPI Component Architecture ASL+ Optimizing Compiler/Disassembler version 20230628 Copyright (c) 2000 - 2023 Intel Corporation File appears to be binary: found 85251 non-ASCII characters, disassembling Binary file appears to be a valid ACPI table, disassembling Input file dsdt.dat, Length 0x72C22 (470050) bytes ACPI: DSDT 0x0000000000000000 072C22 (v39 ALASKA A M I 01072009 INTL 20220331) Pass 1 parse of [DSDT] Firmware Error (ACPI): Failure creating named object [\_SB.PCI0.GPP7.UP00], AE_ALREADY_EXISTS (20230628/dswload-495) ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-372) Could not parse ACPI tables, AE_ALREADY_EXISTS If you can get that decompiled then the _AEI will likely have information useful for figuring out what it matches. I did a quick and dirty modification on acpica code to bypass the error and get dsdt.dat decompiled. Hopefully it doesn't distort things significantly.
```
diff --git a/source/components/dispatcher/dswload.c b/source/components/dispatcher/dswload.c
index ed97abb13..b2af9b40c 100644
--- a/source/components/dispatcher/dswload.c
+++ b/source/components/dispatcher/dswload.c
@@ -465,7 +465,7 @@ AcpiDsLoad1BeginOp (
{
/* The name already exists in this scope */
- if (Node->Flags & ANOBJ_IS_EXTERNAL)
+ //if (Node->Flags & ANOBJ_IS_EXTERNAL)
{
/*
* Allow one create on an object or segment that was
```
Here is the _AEI method found in the dsdt.dsl (full file attached).
```
Method (_AEI, 0, NotSerialized) // _AEI: ACPI Event Interrupts
{
Name (BUFF, ResourceTemplate ()
{
GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0003
}
})
Name (BUNP, ResourceTemplate ()
{
GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullDefault, 0x1388,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0000
}
GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x003D
}
GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x003E
}
GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x003A
}
GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x003B
}
GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0002
}
GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0003
}
GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0009
}
})
If ((G001 == One))
{
M460 (" OEM-ASL-\\_SB.GPIO._AEI return BUNP (MS)\n", Zero, Zero, Zero, Zero, Zero, Zero)
Return (BUNP) /* \_SB_.GPIO._AEI.BUNP */
}
Else
{
M460 (" OEM-ASL-\\_SB.GPIO._AEI return BUFF (S3)\n", Zero, Zero, Zero, Zero, Zero, Zero)
Return (BUFF) /* \_SB_.GPIO._AEI.BUFF */
}
}
```
Created attachment 306296 [details]
dsdt.dsl
This looks like it's the EC trying to wake up the system.
Case (0x03)
{
M000 (0x3903)
M460 (" Clear SCI Status Bit02\n", Zero, Zero, Zero, Zero, Zero, Zero)
M014 (0xFED80200, Zero, Zero, 0x20, 0x04)
If (CondRefOf (\_GPE._L02))
{
M460 (" Call \\_GPE._L02 ()\n", Zero, Zero, Zero, Zero, Zero, Zero)
\_GPE._L02 ()
}
}
Check and make sure that your BIOS and EC firmware is up to date. If it is you probably should report this to your vendor to investigate and explain.
I've also caught this issue on a new system with MB Gigabyte X670E AORUS MASTER, 9700X CPU and openSUSE Leap 15.6(6.4.0-150600.23.17), also checked that the same is reproducible on openSUSE Tumbleweed. For me it looks the same - the same IRQ 7 involved with "GPIO 3 is active" and IR-IO-APIC 7-fasteoi pinctrl_amdthat served this IRQ (and similar not parsed/decompiled DSDT but different sizes/offsets and "v115 ALASKA A M I"). Solutions with adding "gpiolib_acpi.ignore_interrupt=AMDI0030:00@03" kernel parameter and ignore this event works, ie after that there is NO not needed wakeups so far. Tried to communicate with Gigabyte and the final response is: -- QUOTE -- As there are many possiblites that could be the root that triggered the issue, we are unable to confirm the issue without having the product examined/tested. We've tested the platform with Windows 10 (as the supported OS stated on the product spec page), no system reboot issue occurred as you reported. As reminded you on the very first mail, suspend issues related also to the OS. If you would like to isolate the issue related to the OS or not, we suggest you install Windows instead to see if the issue can be solved. Your suggestion mentioned will be forwarded to related parties for their reference as well. -- QUOTE -- However I haven't reported any system reboot, I reported "after attempt to [deep]/S3 Sleep it wakes up maybe in a second" Not sure that I have any willingness to install and try it on windows.... Well it's good you have a workaround for this bug for anyone that encounters it. But if it's the EC that is waking the system (which above findings point at), it will need to be fixed by an update to that. |