I’d really like to play around with the new P-state driver for Ryzen processors in Linux, but even after enabling CPPC (and CPPC Preferred Cores) in the BIOS I’m stuck at the following error message in kernlog:
amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
Has anyone else encountered this? Any suggestions? I have an Asus X570 board with a Zen 3 processor if that makes any difference.
What kernel are you using? Did you add the necessary kernel boot parameters?
Gigabyte Aorus B550 Pro V2 with a 5800X. CPPC is set to auto in BIOS. Using 6.3.5 kernel right now and it works fine after just adding amd_pstate=active to my kernel boot parameters.
6.4-rc5 with amd_pstate=active. 
I use amd_pstate=passive. Everything seems fine with Ubuntu 23.04.
How do you get this log message?
I tried passive too; same thing.
dmesg.
Currently, some of the Zen2 and Zen3 processors support amd-pstate. In the future, it will be supported on more and more AMD processors.
https://www.kernel.org/doc/html/latest/admin-guide/pm/amd-pstate.html
The kernel docs are vague on supported models.
It’s a 5950X, so it’s not exactly an obscure OEM-only QS or anything like that. 
So a few a possibilities. You may need to add “shared_mem” module(seehere)
I would also double check your bios settings and make sure it isn’t disabled within the bios somehow. Beyond that as posted by Zennoe, it’s possible that support hasn’t be deployed for it as of yet. 5950x isn’t going to be as mainstream as a 5600x.
To the best of my understanding this is only required on older kernels. Setting amd_pstate=passive is the equivalent on newer kernels. But sure, I’ll give it (and the initcall_blacklist trick) a try anyway.
There are two options in the BIOS related to CPPC and I’ve toggled them (trying different permutations of Auto/Enable/Disable). I’ve also tried toggling a variety of settings related to ACPI, C states, etc. with no effect.
I mean, the article you linked references kernel version 5.17. I’m running 6.4-rc5, and I’ve verified that the kernel is configured appropriately. So I don’t think that’s the problem.
On the contrary, the enthusiasts who are capable of and willing to patch and compile custom kernels to test new features like this are much more likely to be running a higher-end part. It wouldn’t make any sense to restrict the feature to a lower-end part, and there’s nothing in the code or the forums or anywhere else to support this theory.
Have you tried using a 6.3 kernel (a non RC kernel)?
What does cat /sys/devices/system/cpu/amd-pstate/status spit out?
Currently, some of the Zen2 and Zen3 processors support
amd-pstate. In the future, it will be supported on more and more AMD processors.
https://docs.kernel.org/admin-guide/pm/amd-pstate.html
Not sure how up-to-date that is.
Yes tried with 6.3.6 before jumping to the rc.
Nothing anything here… can’t seem to crack it.
However… I am noticing that there is literally nothing happening in the kernel for e.g. acpi_cpufreq, scaling_governor, energy_performance_preference, etc. I wonder if there’s something in the UEFI BIOS I need to toggle to delegate all that stuff to the OS.
After reading here I became interested in the AMD p-state driver and on my ZEN2 Threadripper platform I am also unable to activate the driver. I have set the kernel parameter, enabled BIOS options that refer to pstates and tried to manually load the driver via the modprobe-command after boot. All to no avail. I opened a support request with my mainboard manufacturer asking if there is anything I can do or if they have info if this combination is even supported, since the kernel documentation is not telling a lot about the supported devices.
This error says one or both of the following true:
If you haven’t done anything weird for your linux setup. Then very likely your UEFI is buggy. Try the latest one, or randomly some of previous releases if you have better luck. Then contact your motherboard support.
I’ve been using AMD p-state driver since patches showed up in the kernel mailing list. I forgot for how long that has been. I woudl say it’s good to have but nothing much to lose if you don’t. That’s for all client processors i.e. low core count processors.
acpi-cpufreq driver hands over to AMD processor to boost and control frequencies. AMD’s implementation inside its Zen2 (in my case) or above are very good already IMO. Hence, little observed improvement in both performance and energy saving by switching to AMD p-state.
Anyway, if you can, all ppl should switch to AMD p-state. lol
I’ve already reached out to Asus support. We’ll see if they can throw me a bone. Thank you!
For me the differences are in minimum frequencies. No idea how much that affects power draw as voltages seem to behave the same. 1.3Ghz idle with normal acpi vs 500Mhz idle with amd_pstate. Boost clocks are the same from what I’ve seen.
found this elsewhere
Check to see if CPPC is enabled in your BIOS/UEFI. If you have a Zen 2 or Zen 3 CPU, make sure ACPI CPPC is enabled if it is not already.
Check to make sure the pstate driver is actually in use:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
If for some reason you did not disable the ACPI CPUFreq in your kernel config, supposedly you can add this to your kernel boot parameters:
initcall_blacklist=acpi_cpufreq_init
This should keep it from loading and conflicting with the amd-pstate driver.
I have to revise me earlier statement, with amd_pstate=passive the driver loads and seems to do it’s thing.
Here’s what’s weird:
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
cat: '/sys/devices/system/cpu/cpu*/cpufreq/scaling_driver': No such file or directory
cpu* = cpu1,cpu2 and so on till you run out of cores.
try
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver