MECHREVO Wujie 14XA (GX4HRXL) wakes up immediately after s2idle entry. This happens regardless of whether the laptop is plugged into AC power, or whether any peripheral is plugged into the laptop. Using `amd_s2idle.py --debug-ec', we found that the laptop has a wakeup event triggered by IRQ 1 (PS/2 Controller) and IRQ 9 (ACPI SCI), and was eventually woken up by IRQ 9. Taking a look at `dmesg', we found that the EC was quite chatty after s2idle entry: [ 1842.317151] PM: suspend-to-idle [ 1842.317178] ACPI: EC: ACPI EC GPE status set [ 1842.317184] ACPI: EC: IRQ (5) [ 1842.317190] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317196] ACPI: EC: Polling enabled [ 1842.317198] ACPI: EC: Command(QR_EC) submitted/blocked [ 1842.317202] ACPI: EC: ACPI EC GPE dispatched [ 1842.317248] ACPI: EC: Event started [ 1842.317259] ACPI: EC: 2: Increase command [ 1842.317264] ACPI: EC: Command(QR_EC) started [ 1842.317271] ACPI: EC: TASK (14) [ 1842.317288] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317294] ACPI: EC: EC_SC(W) = 0x84 [ 1842.317303] ACPI: EC: TASK (14) [ 1842.317324] ACPI: EC: EC_SC(R) = 0x2a SCI_EVT=1 BURST=0 CMD=1 IBF=1 OBF=0 [ 1842.317329] ACPI: EC: TASK (14) [ 1842.317336] ACPI: EC: EC_SC(R) = 0x2a SCI_EVT=1 BURST=0 CMD=1 IBF=1 OBF=0 [...] [ 1842.317399] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317405] ACPI: EC: TASK (14) [ 1842.317412] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317418] ACPI: EC: TASK (14) [ 1842.317425] ACPI: EC: EC_SC(R) = 0x29 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=1 [ 1842.317432] ACPI: EC: EC_DATA(R) = 0x7b [ 1842.317436] ACPI: EC: Command(QR_EC) unblocked [ 1842.317445] ACPI: EC: Polling quirk [ 1842.317448] ACPI: EC: TASK (14) [ 1842.317455] ACPI: EC: EC_SC(R) = 0x28 SCI_EVT=1 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317463] ACPI: EC: Polling enabled [ 1842.317466] ACPI: EC: Command(QR_EC) submitted/blocked [ 1842.317469] ACPI: EC: Polling disabled [ 1842.317472] ACPI: EC: Command(QR_EC) completed by hardware [ 1842.317476] ACPI: EC: Command(QR_EC) stopped [ 1842.317480] ACPI: EC: 1: Decrease command [ 1842.317484] ACPI: EC: Query(0x7b) scheduled [ 1842.317495] ACPI: EC: 2: Increase command [ 1842.317499] ACPI: EC: Command(QR_EC) started [ 1842.317504] ACPI: EC: TASK (14) [ 1842.317516] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317521] ACPI: EC: EC_SC(W) = 0x84 [ 1842.317529] ACPI: EC: TASK (14) [ 1842.317537] ACPI: EC: EC_SC(R) = 0x0a SCI_EVT=0 BURST=0 CMD=1 IBF=1 OBF=0 [ 1842.317543] ACPI: EC: TASK (14) [ 1842.317550] ACPI: EC: EC_SC(R) = 0x0a SCI_EVT=0 BURST=0 CMD=1 IBF=1 OBF=0 [ 1842.317555] ACPI: EC: TASK (14) [...] [ 1842.317638] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317643] ACPI: EC: TASK (14) [ 1842.317650] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317656] ACPI: EC: TASK (14) [ 1842.317663] ACPI: EC: EC_SC(R) = 0x09 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=1 [ 1842.317670] ACPI: EC: EC_DATA(R) = 0x00 [ 1842.317674] ACPI: EC: Command(QR_EC) unblocked [ 1842.317682] ACPI: EC: Polling quirk [ 1842.317685] ACPI: EC: TASK (14) [ 1842.317692] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.317697] ACPI: EC: Polling disabled [ 1842.317700] ACPI: EC: Command(QR_EC) completed by hardware [ 1842.317704] ACPI: EC: Command(QR_EC) stopped [ 1842.317707] ACPI: EC: 1: Decrease command [ 1842.317711] ACPI: EC: Event stopped [ 1842.317723] ACPI: EC: Query(0x7b) started [ 1842.318142] ACPI: EC: Query(0x7b) stopped [ 1842.318150] ACPI: EC: ACPI EC work flushed [ 1842.318158] ACPI: PM: Rearming ACPI SCI for wakeup [ 1842.318169] amd_pmc: SMU idlemask s0i3: 0x1ffb3ebd [ 1842.318193] PM: Triggering wakeup from IRQ 9 [ 1842.318244] ACPI: EC: ACPI EC GPE status set [ 1842.318249] ACPI: EC: IRQ (5) [ 1842.318254] ACPI: EC: EC_SC(R) = 0x08 SCI_EVT=0 BURST=0 CMD=1 IBF=0 OBF=0 [ 1842.318263] ACPI: PM: Rearming ACPI SCI for wakeup I'm not quite sure what the EC was during this time. As `acpi.ec_no_wakeup=1' works around this issue, I believe that the EC had for some reason caused the system to wake up. Browsing the source code, I found that in `drivers/acpi/ec.c', `struct dmi_system_id acpi_ec_no_wakeup[]' records a few machines with incorrect suspend behaviors caused by EC wakeup. As this struct corresponds to a series of machines that needs `acpi.ec_no_wakeup' enabled by default, add GX4HRXL to this struct. Note that I have only matched the motherboard model, as MECHREVO is a "white label" manufacturer using commonly used chassis and motherboards - GX4HRXL may be found in a variety of laptops sold under different brands and model names. Since the reason behind this EC wakeup is not yet clear to me, I'm sending this patch in hope of getting more comments and guidance on how to further debug this issue. Suggested-by: Mingcong Bai <jeffbai@xxxxxxx> Link: https://zhuanlan.zhihu.com/p/730538041 Tested-by: Yemu Lu <prcups@xxxxxxxx> Co-developed-by: Xinhui Yang <cyan@xxxxxxxx> Signed-off-by: Xinhui Yang <cyan@xxxxxxxx> Co-developed-by: Rong Zhang <i@xxxxxxxx> Signed-off-by: Rong Zhang <i@xxxxxxxx> Signed-off-by: Runhua He <hua@xxxxxxx> --- drivers/acpi/ec.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index 3c5f34892..19f1d36a5 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -2329,6 +2329,12 @@ static const struct dmi_system_id acpi_ec_no_wakeup[] = { DMI_MATCH(DMI_PRODUCT_NAME, "83Q3"), } }, + { + /* MECHREVO Wujie 14 Series (GX4HRXL) */ + .matches = { + DMI_MATCH(DMI_BOARD_NAME, "GX4HRXL"), + } + }, { }, }; -- 2.49.0
