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
