| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <eff33a971679fb47f5c9da9fd39f433a8e997089.camel@rong.moe>
Date: Sun, 20 Apr 2025 18:05:23 +0800
From: Rong Zhang <i@...g.moe>
To: Mario Limonciello <mario.limonciello@....com>
Cc: Kexy Biscuit <kexybiscuit@...c.io>, Mingcong Bai <jeffbai@...c.io>,
Yemu Lu <prcups@...m.moe>, Xinhui Yang <cyan@...no.uk>, "Rafael J.
Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
linux-acpi@...r.kernel.org, Runhua He <hua@...c.io>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] ACPI: EC: Set ec_no_wakeup for MECHREVO Wujie 14XA
(GX4HRXL)
Hi Mario,
I noticed a patch [1] of yours fixed an identical issue on old AMD
platforms with outdated platform firmware while another recent patch
[2] set ec_no_wakeup for Lenovo Go S, and you are the author of amd-
debug-tools (hence also amd_s2idle.py). Could you kindly take a look at
this?
I reached Runhua in private, asking him to try disabling
/sys/kernel/irq/1/wakeup and
/sys/bus/serio/devices/serio0/power/wakeup to reproduce the effect of
patch [1]. Doing so also worked around the issue.
[1]: 8e60615e8932 ("platform/x86/amd: pmc: Disable IRQ1 wakeup for
RN/CZN")
[2]: b988685388ef ("ACPI: EC: Set ec_no_wakeup for Lenovo Go S")
Thanks,
Rong
On Fri, 2025-04-18 at 19:22 +0800, Runhua He wrote:
> 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@...c.io>
> Link: https://zhuanlan.zhihu.com/p/730538041
> Tested-by: Yemu Lu <prcups@...m.moe>
> Co-developed-by: Xinhui Yang <cyan@...no.uk>
> Signed-off-by: Xinhui Yang <cyan@...no.uk>
> Co-developed-by: Rong Zhang <i@...g.moe>
> Signed-off-by: Rong Zhang <i@...g.moe>
> Signed-off-by: Runhua He <hua@...c.io>
> ---
> 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"),
> + }
> + },
> { },
> };
>
Powered by blists - more mailing lists