| 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: <e8129e3c-aba9-427e-ad63-bc1ea1bdf0f5@amd.com>
Date: Mon, 28 Apr 2025 13:23:50 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Marcus Bergo <marcusbergo@...il.com>,
"Rafael J. Wysocki" <rafael@...nel.org>
Cc: mark.pearson@...ovo.com, linux-acpi@...r.kernel.org,
platform-driver-x86@...r.kernel.org, lenb@...nel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD platforms
after suspend/resume
On 4/28/2025 4:51 AM, Marcus Bergo wrote:
> Yes, it does.
>
OK thanks for confirming. Considering your finding with this patch
you've shared and knowing there is a timing dependency that delaying the
next s2idle cycle helps I do wonder if we should keep exploring.
Rafael, do you have thoughts here? Specifically do you think it's worth
revisiting if b5539eb5ee70 was the correct move.
> On Sun, Apr 27, 2025 at 11:06 PM Mario Limonciello
> <mario.limonciello@....com <mailto:mario.limonciello@....com>> wrote:
>
> On 4/27/2025 1:34 PM, M. Bergo wrote:
> > It does make it work fine for me, I saw the clock/timing
> interference
> > and this sane this problem for Lenovo as well.
>
> Huh? I think you have a typo; but I don't know what you actually meant.
>
> So you're saying the timing patch helps your system as well?
>
> Thanks,
>
> >
> > On 4/24/25 11:11 AM, Mario Limonciello wrote:
> >> On 4/19/2025 1:03 PM, Mario Limonciello wrote:
> >>> On 4/19/2025 4:28 AM, M. Bergo wrote:
> >>>> From 881e57c87b9595c186c2ca7e6d35d0a52c1a10c2 Mon Sep 17
> 00:00:00 2001
> >>>> From: Marcus Bergo <marcusbergo@...il.com
> <mailto:marcusbergo@...il.com>>
> >>>> Date: Sat, 19 Apr 2025 05:19:05 -0300
> >>>> Subject: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD
> >>>> platforms after
> >>>> suspend/resume
> >>>>
> >>>> Several AMD-based laptop models (Lenovo P15v Gen 3, P16v Gen
> 1, HP
> >>>> EliteBook 845 G10)
> >>>> experience a CPU frequency limitation issue where the
> processor gets
> >>>> stuck at
> >>>> approximately 544MHz after resuming from suspend when the
> power cord
> >>>> is unplugged
> >>>> during sleep. This issue makes the systems practically unusable
> >>>> until a full
> >>>> power cycle is performed.
> >>>>
> >>>> The root cause was traced to commit b5539eb5ee70 ("ACPI: EC: Fix
> >>>> acpi_ec_dispatch_gpe()") which restored the behavior of
> clearing the
> >>>> GPE
> >>>> in acpi_ec_dispatch_gpe() function to prevent GPE storms.
> While this
> >>>> fix is
> >>>> necessary for most platforms to prevent excessive power
> consumption
> >>>> during
> >>>> suspend-to-idle, it causes problems on certain AMD platforms by
> >>>> interfering
> >>>> with the EC's ability to properly restore power management
> settings
> >>>> after resume.
> >>>>
> >>>> This patch implements a targeted workaround that:
> >>>> 1. Adds DMI-based detection for affected AMD platforms
> >>>> 2. Adds a function to check if we're in suspend-to-idle mode
> >>>> 3. Modifies the acpi_ec_dispatch_gpe() function to handle AMD
> >>>> platforms specially:
> >>>> - For affected AMD platforms during suspend-to-idle, it
> advances
> >>>> the
> >>>> transaction without clearing the GPE status bit
> >>>> - For all other platforms, it maintains the existing
> behavior of
> >>>> clearing
> >>>> the GPE status bit
> >>>>
> >>>> Testing was performed on a Lenovo P16v Gen 1 with AMD Ryzen 7 PRO
> >>>> 7840HS and
> >>>> confirmed that:
> >>>> 1. Without the patch, the CPU frequency is limited to 544MHz
> after the
> >>>> suspend/unplug/resume sequence
> >>>> 2. With the patch applied, the CPU properly scales up to its
> maximum
> >>>> frequency
> >>>> (5.1GHz) after the same sequence
> >>>> 3. No regressions were observed in other EC functionality
> (battery
> >>>> status,
> >>>> keyboard backlight, etc.)
> >>>> 4. Multiple suspend/resume cycles with different power states
> were
> >>>> tested
> >>>> without issues
> >>>>
> >>>> The patch was also verified not to affect the behavior on Intel-
> >>>> based systems,
> >>>> ensuring that the GPE storm prevention remains effective where
> needed.
> >>>>
> >>>> Fixes: b5539eb5ee70 ("ACPI: EC: Fix acpi_ec_dispatch_gpe()")
> >>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218557
> <https://bugzilla.kernel.org/show_bug.cgi?id=218557>
> >>>> Reported-by: Mark Pearson <mark.pearson@...ovo.com
> <mailto:mark.pearson@...ovo.com>>
> >>>> Signed-off-by: Marcus Bergo <marcusbergo@...il.com
> <mailto:marcusbergo@...il.com>>
> >>>
> >>> Great finding with this being a potential root cause of this
> behavior
> >>> (at least from a Linux perspective).
> >>>
> >>> Although this helps, I'm not really a fan of the tech debt
> >>> accumulated by needing to quirk this on a system by system
> basis as a
> >>> bandage.
> >>>
> >>> At least for HP someone said that this commit happens to help them
> >>> for the same issue you're describing:
> >>>
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-
> <https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform->
> >>> drivers- x86.git/commit/?
> >>> h=fixes&id=9f5595d5f03fd4dc640607a71e89a1daa68fd19d
> >>>
> >>> That was surprising to me, but it must be changing the timing
> of some
> >>> of the code running in HP's EC. Since you happen to have a Lenovo
> >>> system does it happen to help the Lenovo EC too?
> >>>
> >>> Mark, comments please?
> >>>
> >> Someone just reported that the timing delay patch helped their
> Lenovo
> >> system as well. Can you see if it helps you too?
>
>
>
> --
>
>
> *
> *
> *
> Marcus Bergo*
Powered by blists - more mailing lists