[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 #10 from Ivan Shapovalov (intelfx@intelfx.name) ---
(In reply to Mario Limonciello (AMD) from comment #5)
> It looks like this message is being emitted specifically from the calls in
> amd_set_max_freq_ratio().
> 
> You system is a shared memory design not a MSR design.
> "[  +0.000016] amd_pstate: AMD CPPC shared memory based functionality is
> supported"

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.

> This looks like the calltrace:
> amd_set_max_freq_ratio
> ->amd_get_boost_ratio_numerator
> ->->amd_detect_prefcore
> ->->->amd_get_highest_perf
> ->->->->cppc_get_highest_perf
> ->->->->->cppc_get_perf
> 
> The first error you see is "No CPC descriptor for CPU:1" which comes from
> cppc_get_perf().
> 
> Can you please share your acpidump?  It sure seems like a BIOS bug to me.

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:

```
Oct 28 17:13:08 kernel: ACPI CPPC: CPPC v2 _OSC not acked
Oct 28 17:13:08 kernel: ACPI CPPC: Parsed CPC struct for CPU: 0
Oct 28 17:13:08 kernel: ACPI CPPC: TX completed. CMD sent:0, ret:0
Oct 28 17:13:08 kernel: ACPI CPPC: TX completed. CMD sent:0, ret:0
Oct 28 17:13:08 kernel: ACPI CPPC: No CPC descriptor for CPU:1
Oct 28 17:13:08 kernel: Could not retrieve highest performance (-19)
<...>
Oct 28 17:13:08 kernel: amd_pstate: AMD CPPC shared memory based functionality
is supported
Oct 28 17:13:08 kernel: ACPI CPPC: TX completed. CMD sent:0, ret:0
Oct 28 17:13:08 kernel: ACPI CPPC: TX completed. CMD sent:0, ret:0
Oct 28 17:13:08 kernel: AMD CPPC preferred core is supported (highest perf:
0xe7)
```

It's even more interesting that the debug logs from the amd-pstate flow you
described earlier appear to be interleaved with debug logs from
acpi_cppc_processor_probe():

```
Oct 28 17:13:08 kernel: ACPI CPPC: CPPC v2 _OSC not acked
Oct 28 17:13:08 kernel: ACPI CPPC: Parsed CPC struct for CPU: 0
Oct 28 17:13:08 kernel: ACPI CPPC: TX completed. CMD sent:0, ret:0
Oct 28 17:13:08 kernel: ACPI CPPC: TX completed. CMD sent:0, ret:0
Oct 28 17:13:08 kernel: ACPI CPPC: No CPC descriptor for CPU:1
Oct 28 17:13:08 kernel: Could not retrieve highest performance (-19)
Oct 28 17:13:08 kernel: Monitor-Mwait will be used to enter C-1 state
Oct 28 17:13:08 kernel: ACPI CPPC: CPPC v2 _OSC not acked
Oct 28 17:13:08 kernel: ACPI CPPC: Parsed CPC struct for CPU: 1 <-- THIS
```

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?

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

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