[Bug 219431] [6.12] amd-pstate / Ryzen 5xxx (Zen 3, Vermeer): Could not retrieve highest performance (-19)

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=219431

--- Comment #11 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
>I assumed that all Zen 3 desktop parts are ACPI CPPC-based rather than
>MSR-based? That's why I mentioned Vermeer in both my original mail and this
>bug report.

Vermeer is a shared memory based design.  All the newer designs are MSR based.

> There is also an interesting observation, that at some point *after* this
> warning we get a pr_debug() from the end of amd_detect_prefcore(), which
> indicates that the latter is called again and this error does not happen
> anymore:

Yeah that's why I was wondering if there was a functional issue. It seems like
this is going to influence some of the frequency invariance code that's set up
earlier on.

> I'm not familiar with control flow in these subsystems, but isn't it possible
> that we are simply racing with ACPI (and thus CPPC) subsystem initialization?

acpi_init() calls 
acpi_bus_init()() calls 
acpi_bus_osc_negotiate_platform_control() 
which sets osc_sb_cppc2_support_acked

Here is the more full call path that fails:

acpi_init() calls
acpi_scan_init() calls
acpi_processor_init() 

which loads "processor" kernel module

From "processor" kernel module:

acpi_processor_driver_init() calls
acpi_soft_cpu_online() calls
__acpi_processor_start() calls 
acpi_cppc_processor_probe() calls 
arch_init_invariance_cppc() which is a macro to call 
init_freq_invariance_cppc().


I'm not sure I understand why CPPC v2 _OSC isn't acked though at the right
time.  

Can you use ftrace or annotate the functions with some printk's to figure it
out perhaps from what I've shared?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.