Re: amd-pstate fails to initialize on HP 255 G8 (Ryzen 5 5500U) although ACPI CPPC works under Windows

[Mario Limonciello <mario.limonciello@amd.com>]

[-- Attachment #1: Type: text/plain, Size: 3917 bytes --]



On 7/31/26 09:56, Giusy wrote:
> Hello,
> 
> I would like to report what appears to be an amd-pstate initialization 
> issue on my laptop.
> 
> 
> Hardware
> ========
> 
> System: HP 255 G8 Notebook PC
> CPU: AMD Ryzen 5 5500U (Zen 2)
> BIOS: F.45 (2025-12-09)
> 
> 
> Software
> ========
> 
> Distribution: Arch Linux
> Kernel: 7.1.5-arch1-1 (same behavior also observed with linux-zen 7.1.x)
> 
> Kernel command line:
> 
>     amd_pstate=active amd_pstate.shared_mem=1
> 
> 
> Problem
> =======
> 
> Initially, the BIOS did not expose any user-accessible CPPC option. As 
> an experiment, I used Smokeless UMAF to enable the hidden CPPC setting. 
> After enabling it:
> 
>   * Windows 11 successfully exposes and uses ACPI Collaborative
>     Processor Performance Control.
>   * Linux still fails to initialize amd-pstate.
> 
> The amd_pstate driver fails to initialize with:
> 
>      amd_pstate: The CPPC feature is supported but currently disabled by 
> the BIOS.
>      amd_pstate: AMD CPPC shared memory based functionality is supported
>      amd_pstate: failed to set energy perf value (-524)
>      amd_pstate: Failed to initialize CPU X: -524
>      amd_pstate: failed to register with return -19
> 
> Despite this message:
> 
>   * ACPI _CPC objects are present in the firmware.
>   * Linux parses all _CPC objects successfully.
>   * /sys/devices/system/cpu/cpu0/acpi_cppc/ is populated and exposes
>     valid CPPC information.
> 
> As I said before, the vendor BIOS does not expose any CPPC option in 
> Setup. I enabled the hidden CPPC firmware option using Smokeless UMAF 
> for testing purposes. Windows 11 subsequently uses ACPI Collaborative 
> Processor Performance Control correctly, while Linux still reports that 
> CPPC is disabled by the BIOS and fails to initialize amd-pstate.
> 
> 
> Windows evidence
> ================
> 
> Windows Event ID 55 (Microsoft-Windows-Kernel-Processor-Power) reports 
> for every processor:
> 
>      Performance state type:
>      ACPI Collaborative Processor Performance Control
> 
> The Windows power management report also reports:
> 
>      Performance control type:
>      ACPI Collaborative Processor Performance Control
> 
> This suggests that the firmware is exposing functional CPPC interfaces 
> and Windows is able to use them correctly.
> 
> 
> Linux diagnostics
> =================
> 
> Relevant kernel messages include:
> 
>      ACPI CPPC: Parsed CPC struct for CPU: 0
>      ...
>      ACPI CPPC: Parsed CPC struct for CPU: 11
> 
> followed by
> 
>      amd_pstate: The CPPC feature is supported but currently disabled by 
> the BIOS.
> 
> and finally
> 
>      amd_pstate: failed to register with return -19
> 
> Additionally, I tested the amd-debug-tools package (amd-pstate v0.2.20). 
> Running:
> 
>      sudo amd-pstate triage
> 
> results in:
> 
>      Unable to gather CPU information
> 
> strace shows that the tool attempts to access /sys/devices/system/cpu/ 
> amd_pstate/, but those sysfs entries are absent because the amd_pstate 
> driver never successfully registers. I believe this is a consequence of 
> the initialization failure rather than a separate bug.
> 
> I have attached various files:
> 
>   * complete journal from boot
>   * filtered amd_pstate and CPPC logs
>   * ACPI tables
>   * cpuid output
>   * acpi_cppc sysfs dump
>   * cpufreq information
>   * amd-pstate triage output
>   * Windows 11 Event ID 55 output
>   * Windows 11 powercfg output
> 
> 
> Question
> ========
> 
> Since Windows successfully uses ACPI Collaborative Processor Performance 
> Control on the same firmware, is this expected behavior, or could this 
> indicate an amd-pstate compatibility issue with Linux platform?
> 
> If additional debugging information or patches would be useful, I'd be 
> happy to test them.
> 
> Thank you for your time.
> 
> 

Can you have a try with this attached patch?

[-- Attachment #2: 0001-ACPI-CPPC-Don-t-gate-FFH-EPP-writes-on-flexible-addr.patch --]
[-- Type: text/x-patch, Size: 3092 bytes --]

From 39bd669bb0aeb2493ca4a07ce70d83edf926e9d0 Mon Sep 17 00:00:00 2001
From: Mario Limonciello <mario.limonciello@amd.com>
Date: Mon, 10 Aug 2026 14:17:35 -0500
Subject: [PATCH] ACPI: CPPC: Don't gate FFH EPP writes on flexible address
 space _OSC

cppc_set_epp_perf() requires osc_cpc_flexible_adr_space_confirmed before
writing the EPP and autonomous-selection registers, even when they live
in FFH.  FFH access is a direct rdmsr/wrmsr and does not depend on that
_OSC bit, which only governs CPPC controls in SystemMemory/SystemIO.

As a result amd-pstate active mode fails to initialize on platforms whose
firmware does not ack CPPC in _OSC but whose EPP register is a working FFH
MSR.  On an HP 255 G8 (Ryzen 5 5500U) reads succeed via the _CPC parse
path's cpc_supported_by_cpu() fallback, but the EPP write is rejected:

    amd_pstate: failed to set energy perf value (-524)
    amd_pstate: failed to register with return -19

Gate only SystemMemory on osc_cpc_flexible_adr_space_confirmed and allow
FFH unconditionally, matching the _CPC parse path and cpc_ffh_supported().

Fixes: aaf21ac93909 ("ACPI: CPPC: Add support for setting EPP register in FFH")
Reported-by: Giusy <kurmikon@yahoo.com>
Closes: https://lore.kernel.org/linux-pm/e4259474-fa4f-4ed8-8a7f-1a3a2521acd3@yahoo.com/
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/acpi/cppc_acpi.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 84740ad8ca63a..3a0cfe2d97c54 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -1642,10 +1642,18 @@ int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable)
 	auto_sel_reg = &cpc_desc->cpc_regs[AUTO_SEL_ENABLE];
 	epp_set_reg = &cpc_desc->cpc_regs[ENERGY_PERF];
 
+	/*
+	 * The flexible address space _OSC ack is only needed for
+	 * SystemMemory/SystemIO; FFH is accessed directly and always available.
+	 */
 	epp_ffh_sysmem = CPC_SUPPORTED(epp_set_reg) &&
-		(CPC_IN_FFH(epp_set_reg) || CPC_IN_SYSTEM_MEMORY(epp_set_reg));
+		(CPC_IN_FFH(epp_set_reg) ||
+		 (CPC_IN_SYSTEM_MEMORY(epp_set_reg) &&
+		  osc_cpc_flexible_adr_space_confirmed));
 	autosel_ffh_sysmem = CPC_SUPPORTED(auto_sel_reg) &&
-		(CPC_IN_FFH(auto_sel_reg) || CPC_IN_SYSTEM_MEMORY(auto_sel_reg));
+		(CPC_IN_FFH(auto_sel_reg) ||
+		 (CPC_IN_SYSTEM_MEMORY(auto_sel_reg) &&
+		  osc_cpc_flexible_adr_space_confirmed));
 
 	if (CPC_IN_PCC(epp_set_reg) || CPC_IN_PCC(auto_sel_reg)) {
 		if (pcc_ss_id < 0) {
@@ -1671,8 +1679,7 @@ int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable)
 		/* after writing CPC, transfer the ownership of PCC to platform */
 		ret = send_pcc_cmd(pcc_ss_id, CMD_WRITE);
 		up_write(&pcc_ss_data->pcc_lock);
-	} else if (osc_cpc_flexible_adr_space_confirmed &&
-		   (epp_ffh_sysmem || autosel_ffh_sysmem)) {
+	} else if (epp_ffh_sysmem || autosel_ffh_sysmem) {
 		if (autosel_ffh_sysmem) {
 			ret = cpc_write(cpu, auto_sel_reg, enable);
 			if (ret)
-- 
2.43.0