Re: Warnings `Could not retrieve perf counters (-19)` and `amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled` (Dell PowerEdge R7625, AMD EPYC 9174F)

[Paul Menzel]

Dear Mario,


Am 11.02.25 um 17:18 schrieb Mario Limonciello:
> On 2/11/2025 10:12, Paul Menzel wrote:

> > Am 28.01.25 um 16:08 schrieb Paul Menzel:
> > > [Cc: +x86 maintainers and ACPI list]
> >
> > > Am 28.01.25 um 11:49 schrieb Paul Menzel:
> > >
> > > > Thank you for your quick replies. Gautham, messages with HTML are 
> > > > rejected by Linux kernel lists.
> > > >
> > > >
> > > > Am 28.01.25 um 04:51 schrieb Shenoy, Gautham Ranjal:
> > > >
> > > > > As Mario mentioned, you need to enable the CPPC option. Looking for 
> > > > > some of the Dell PowerEdge documentation, there is an option called 
> > > > > "Collaborative CPU Performance Control" (https://www.dell.com/ 
> > > > > support/manuals/en-in/poweredge-r730/r730_ompublication/system- 
> > > > > profile-settings-details?guid=guid-2e9b46a1-71e3-4072-9d86- 
> > > > > db648757f0e6&lang=en-us).
> > > > >
> > > > > [cid:fe57df8f-3d99-4ea0-8f6e-b0daae49bb0e]
> > > > > Can you please try enabling it ?
> > > >
> > > > You quoted the Dell PowerEdge R730. I couldn’t find it in the *Dell 
> > > > PowerEdge R7625 Installation and Service Manual* [1], and also it’s 
> > > > not listed in the iDRAC9 Web site (attached with added `.txt` 
> > > > extension to trick the Linux list).
> > >
> > > The amd_pstate warning seems to be related to the perf counters 
> > > warning Linux prints earlier:
> > >
> > >      $ dmesg --level alert,crit,err,warn
> > >      [    2.666393] Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!
> > >      [    8.109446] Could not retrieve perf counters (-19)
> > >      [    9.386551] scsi 0:0:4:0: set ignore_delay_remove for  handle(0x0012)
> > >      [    9.487804] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
> > >      [   14.726193] wmi_bus wmi_bus-PNP0C14:00: [Firmware Bug]: WQBC data block query control method not found
> > >
> > > x86 maintainers, the original report with the Linux logs attached is 
> > > in the archive [3].
> > >
> > > It looks like, there is something missing in the Dell firmware to 
> > > enable the feature.
> > >
> > > The perf counters warning is from `amd_set_max_freq_ratio()` in 
> > > `arch/ x86/kernel/acpi/cppc.c`:
> > >
> > > ```
> > > static void amd_set_max_freq_ratio(void)
> > > {
> > >          struct cppc_perf_caps perf_caps;
> > >          u64 numerator, nominal_perf;
> > >          u64 perf_ratio;
> > >          int rc;
> > >
> > >          rc = cppc_get_perf_caps(0, &perf_caps);
> > >          if (rc) {
> > >                  pr_warn("Could not retrieve perf counters (%d)\n", rc);
> > >                  return;
> > >          }
> > >          […]
> > > }
> > > ```
> > >
> > > With
> > >
> > >      include/uapi/asm-generic/errno-base.h:#define    ENODEV 19    /* No such device */
> > >
> > > this is returned by in `drivers/acpi/cppc_acpi.c`:
> > >
> > > ```
> > > /**
> > >   * cppc_get_perf_caps - Get a CPU's performance capabilities.
> > >   * @cpunum: CPU from which to get capabilities info.
> > >   * @perf_caps: ptr to cppc_perf_caps. See cppc_acpi.h
> > >   *
> > >   * Return: 0 for success with perf_caps populated else -ERRNO.
> > >   */
> > > int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps)
> > > {
> > >          struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpunum);
> > >          […]
> > >          if (!cpc_desc) {
> > >                  pr_debug("No CPC descriptor for CPU:%d\n", cpunum);
> > >                  return -ENODEV;
> > >          }
> > >          […]
> > > }
> > > ```
> >
> > @AMD folks, just for clarity. Did Dell something with their firmware? 
> > If so, are you going to work with Dell on a solution, or do I need to 
> > report the issue to them?
>
> I feel if there is a BIOS bug in hardware you purchased, you should 
> report a bug to the hardware creator for them to fix.

I made the service request 205423744 on February 12th, 2025, and after 
collecting the details until February 14th, 2025, Dell replied on March 
4th, 2025, that there L3 support and engineering team was able to 
reproduce the issue, and they are going to provide a firmware update, 
currently estimated for June.

I am still surprised, that Dell’s QA overlooked this. Does AMD provide 
them test suites (does FWTS check for this). `dmesg --level=warning` is 
unfortunately not empty, so maybe they ignore it.

Would it make sense to make the warning an error, so it’s less likely 
overlooked?


Kind regards,

Paul