How to use AMD P-State in Linux

linuxkernels/linux-amd              5.18.v.12-1   5.18.v.13-1            0,00 MiB            82,62 MiB
linuxkernels/linux-amd-headers      5.18.v.12-1   5.18.v.13-1            0,00 MiB            13,89 MiB

let`s try that… looks like linuxkernel repo just updated to that one…

installed Linux-amd 5.18.13 just now, still acpi-cpufreq here

cpupower frequency-info results:
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 1.20 GHz - 3.20 GHz
available frequency steps: 3.20 GHz, 1.30 GHz, 1.20 GHz
available cpufreq governors: performance schedutil
current policy: frequency should be within 1.20 GHz and 3.20 GHz.
The governor “schedutil” may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 2.07 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: no

i am back in:
2022-07-22_15-58
amd_pstate.shared_mem=1

any other steps done or just installed linux-amd 5.18.13?

It worked for me before (5.18.10) but even with the patch included in 5.18.13 still no luck here

it is about to check if you need amd_pstate.shared_mem=1 as kernel parameter or not … in your grub-cfg…

Looks like it is working also on my desktop Ryzen 3800X

[ricklinux@rick-ms7c37 ~]$ cpupower frequency-info
analyzing CPU 0:
  driver: amd-pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 131 us
  hardware limits: 550 MHz - 4.56 GHz
  available cpufreq governors: performance schedutil
  current policy: frequency should be within 550 MHz and 4.56 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 571 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.56 GHz.
    AMD PSTATE Nominal Performance: 142. Nominal Frequency: 3.90 GHz.
    AMD PSTATE Lowest Non-linear Performance: 64. Lowest Non-linear Frequency: 1.76 GHz.
    AMD PSTATE Lowest Performance: 21. Lowest Frequency: 550 MHz.
[ricklinux@rick-ms7c37 ~]$ 

tried with amd_pstate.shared_mem=1 and without but still no luck. Anyway i hope 5.19 will bring it back

it is fixed here

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
amd-pstate
$ uname -a
Linux eos 5.18.13-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 22 Jul 2022 13:05:04 +0000 x86_64 GNU/Linux
1 Like

fixed also in 5.18.13 and with validation patch on manjaro kernel 5.18.12

1 Like

After long research i think the reason why it doesn’t work is because i have a Asus laptop again … found some information pointing in that direction. However i still don’t get it why it worked with 5.18.10-AMD then.

One thing is sure now this will be my last Asus laptop for sure now. (Tuf A15 AMD 5800H cpu Model FA506QM)

Your laptop should work mostly OOTB just loading the amd pstate driver if it has a 5800H. Those CPU it was a requirement for the systems to support CPPC afaik so idk whats going on there.

to be honest i have no idea anymore why it loaded on 5.18.10 but not on 5.18.13 anymore after it got fixed again, i give up currently, been trying to fix this the whole day already and well kinda fed up with up now.

Did you add amd_pstate for MODULES in /etc/mkinitcpio.conf, then run sudo mkinitcpio -P?

yup tried it also but it gave me an error: ==> ERROR: module not found: `amd_pstate’

Still with 5.18.10 i did not need this line.
By the way 5.18.14-AMD released, still acpi-cpufreq in use

Can you post the output of lscpu?

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 7 5800H with Radeon Graphics
CPU family: 25
Model: 80
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Stepping: 0
Frequency boost: enabled
CPU(s) scaling MHz: 40%
CPU max MHz: 3200.0000
CPU min MHz: 1200.0000
BogoMIPS: 6390.81
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clf
lush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm cons
tant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pc
lmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16
c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3d
nowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext p
erfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmc
all fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx clflusho
pt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm
_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt
lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists paus
efilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke va
es vpclmulqdq rdpid overflow_recov succor smca fsrm
Virtualization features:
Virtualization: AMD-V
Caches (sum of all):
L1d: 256 KiB (8 instances)
L1i: 256 KiB (8 instances)
L2: 4 MiB (8 instances)
L3: 16 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB fil
ling
Srbds: Not affected
Tsx async abort: Not affected

time i dump laptops i guess and go back to decent desktops

quick and dirty fix … this can be done on my end?

You could compile the kernel by yourself, fixing the code mentioned in that patch, yes.
Or you wait for the kernel dev’s to fix it…

Well i guess that means waiting then