As far as I have read, AMD P-State is now the default and should be enabled in full active mode, however since upgrading to 6.5.9-1-MANJARO the fallback acpi-cpufreq driver has loaded instead.
Is this intentional? Has P-State been disabled due to a bug? I couldn’t find anything in the 6.5.9 changelog on kernel.org to show this is an upstream decision.
if you refer to this point
for amd-pstate-epp , it needs a kconfig X86_AMD_PSTATE_DEFAULT_MODE switch if wishing to change the default mode of operation for the AMD P-State driver on supported platforms
you can also add on boot
amd_pstate=passive (kernel 6.3 or more )
amd_pstate=active ( kernel 6.5 or more)
amd_pstate=guided ( kernel 6.6 or more )
see this
I get with this best performance results on my Ryzen 3900X
passive and active feels slowly on ZEN2
Please look at the title of the article you linked to… it says it defaults to “active”. And it has been defaulting to Active for all the versions of kernel 6.5 I have run, right up until I upgraded to 6.5.9-1, at which point it now is disabled by default and must be forced on.
I am assuming that this is a change made by the Manjaro team, and I am just trying to work out if the change was made for a reason or in error.
Thanks for the advice, but it’s not what I am trying to get addressed here.
I have been running P-State for a long time, since 5.9. With the release of 6.5 I was able to remove the kernel config and it defaulted to Active as expected, but the behaviour changed with the release of kernel 6.9.5-1.
I am trying to establish if this change was made by the Manjaro team because of a bug or other issue, or if it was disabled by mistake.
Nothing has been changed in the kernel config relating to AMD_PSTATE, as you can verify yourself by looking at the Manjaro linux65 repository.
And it goes on to say;
The AMD P-State driver is now used by default rather than CPUFreq for Zen 2 and newer platforms with the ACPI CPPC (Collaborative Processor Performance Control)
Unfortunately, many (most?) Zen 2/3 systems don’t report CPPC support correctly. Mine doesn’t (Ryzen 5800X on MSI MAG B550 TOMAHAWK).
$ lscpu | grep "cppc"
$
So the P-State driver is enabled but it doesn’t get loaded automatically because it doesn’t see CPPC support even though it is definitely enabled in bios.
$ journalctl -b | grep "pstate"
Nov 08 03:19:47 RYZEN-5800X kernel: amd_pstate: driver load is disabled, boot with specific mode to enable this
where “boot with specific mode” means use the amd_pstate parameter.
Right, I can see what’s happened…
I updated to the latest motherboard firmware last week and the new firmware is not advertising CPPC correctly, and I had not noticed the loss of CPPC and P-State until I started validating 6.5.9-1.
Off to the Gigabyte support site to report the issue, and then revert to the old firmware, I guess.
6.5.9 should normal default to 3 (EPP) as documented here: [PATCH v2 3/4] cpufreq: amd-pstate: Add a kernel config option to set default mode config · 09eac27df63940d1666adfe027f0c6fb13e40d43 · Packages / Core / linux65 · GitLab
Yes it should, which is why I was surprised when it stopped working as expected.
My (probable) mistake was attributing the changed behaviour to the updated kernel, not to the firmware I applied recently, though I thought I had confirmed P-State was still working after I did the firmware update, however I am unsure enough that I now have to do a bunch of testing to confirm the root cause.
I am going to roll back my firmware and confirm that is the root cause. I’ll have to roll forward again to get the security fixes in the latest AGESA back, but I really should confirm that it’s the firmware and not actually a bug in the CPPC driver in the kernel. I am also going to roll back my kernel a couple of versions to confirm that they also don’t work with the latest motherboard firmware. If CPPC/P-State works with old kernels and the latest firmware it confirms the problem is in the kernel, however if CPPC/P-State works on all kernels with the old firmware it confirms the problem is in the firmware.
I remember when PCs where rather simple affairs and there weren’t so many things to go wrong and so much validation wasn’t needed. Ah well, ups and downs.
I will report back when I have had a chance to test and confirm where the fault is.