Cannot change CPU core voltage using zenstates.py
edumarinfabregas opened this issue · 7 comments
Hi all,
Recently, I have been testing this tool in my AMD Ryzen 5 PRO 2400G.
While I managed to change the frequency to overclock my CPU, I haven't been able to modify the CPU core voltage. For my experiments, I first disabled all pstates except for p0 and then I tried to change the VID corresponding to p0 to different values. Yet, using zenmonitor to measure the current CPU core voltage, I observed that these values were ignored by the CPU (they were completely different to the ones I saw in zenmonitor).
Do you have any idea why this tool cannot change the CPU core voltage in my machine?
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model: 17
model name: AMD Ryzen 5 PRO 2400G with Radeon Vega Graphics
stepping: 0
microcode: 0x8101016
cpu MHz: 3064.760
cache size: 512 KB
physical id: 0
siblings: 8
core id: 0
cpu cores: 4
apicid: 0
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
bugs: sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips: 7186.57
TLB size: 2560 4K pages
clflush size: 64
cache_alignment: 64
address sizes: 43 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro [13] [14]
sudo python zenstates.py -l
P0 - Enabled - FID = 90 - DID = 9 - VID = 70 - Ratio = 32.00 - vCore = 0.85000
P1 - Disabled
P2 - Disabled
P3 - Disabled
P4 - Disabled
P5 - Disabled
P6 - Disabled
P7 - Disabled
C6 State - Package - Disabled
C6 State - Core - Disabled
cpupower frequency-info
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.60 GHz - 3.60 GHz
available frequency steps: 3.60 GHz, 2.30 GHz, 1.60 GHz
available cpufreq governors: conservative ondemand userspace powersave performance schedutil
current policy: frequency should be within 3.60 GHz and 3.60 GHz.
The governor "userspace" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.17 GHz (asserted by call to kernel)
boost state support:
Supported: no
Active: no
***** UPDATE *****
I run "cpuid" and got the following extra info regarding the advanced power management features.
Would it be possible that the tool doesn't work because the frequency ID (FID) control and the voltage ID (VID) control are set to "false"?
Advanced Power Management Features (0x80000007/edx):
temperature sensing diode = true
frequency ID (FID) control = false
voltage ID (VID) control = false
thermal trip (TTP) = true
thermal monitor (TM) = true
software thermal control (STC) = false
100 MHz multiplier control = false
hardware P-State control = true
TscInvariant = true
I have the same issue on a Ryzen 3600
Changing PStates does not work as expected. It's not an issue with the script.
The only thing I was able to achieve by changing P-States is setting the idle frequency (PState2), otherwise the CPU adjusts itself depending on load, temperature and power limits.
@mhury I've updated my fork with support for APUs: https://github.com/irusanov/ZenStates-Linux Unfortunatelly, the only way to overcome the problem is by using P-States. I've tested on 240GE and 3000G - both desktop APUs. I guess you could use the original script as well, there's what you should do to force the CPU in OC mode and set higher frequency than what P0 allows.
- Change DID of P0 to original value divided by 2
targetDID = DID / 2 - Adjust FID and VID accordingly
This is the only way I've found so far. They don't respond to anything else.
@iopq The update version of my fork works on Matisse, however it's manual OC only in this case. P-States don't seem to be respected.
@irusanov what do you mean "force the CPU in OC mode?" What's the point of Zenstates if you just have to OC manually from the BIOS anyway? How does changing P-States effect anything at all, if that's the case?
Wait you mean in your GUI, I didn't see your fork had a GUI available. Interesting.
But I wonder why our CPUs are showing as "False" for FID and Voltage control in cpuid? That would seem to indicate that this original Zenstates would never have any chance of working, yet it apparently does work on Zen1 CPUs. It definitely doesn't work for Zen2 though.
@gardotd426 I couldn't quite get what you're saying, but to put it simple (I hope):
-
Zen1 and APU can only be controlled by P-States, yet setting a higher P-State than default P0 puts the CPU in "OC Mode". That's with newer BIOSes. If you're using a very old BIOS, then old behavior is probably still valid.
-
Some AGESA versions ago Zen1 supported something like a "Full Manual OC mode", which completely ignored P-States and you could set OC ferquency and OC VID. This is not working anymore with recent AGESA updates. That's why it is set to False, which essentially hides OC tab, but P-States tab is still active.
-
Zen2 didn't really respect P-States. I noticed multicore boost can now be configured via P0 state, but need more testing. So it vastly depends on AGESA version. Full Manual OC mode still works and can be enabled or disabled on the fly (no need to set it in BIOS).
The reality is the only reliable way to control what the CPU is doing is to configure power limits, but when increasing them, it will still be thermally limited. So, yes...the initial point of the script is sadly lost and I or the original author can't do anything about it.
PS: Ah, I've scrolled up and now I see what you mean - you're talking about the extended cpuid instruction 0x80000007.
From the public documentation:
VID: Voltage ID control. Read-only. Reset: Fixed,0. Function replaced by HwPstate
FID: Frequency ID control. Read-only. Reset: Fixed,0. Function replaced by HwPstate.
SOLUTION FOUND
Had the same issue:
I was having this same issue where changing the voltage of a PSTATE does not work, even in the BIOS. Changing CPU voltage using Ryzen Master in Windows also did not work.
The Solution:
The solution is to change your CPU CLOCK RATIO in BIOS to be above the base clock of your CPU.
For Example:
I am using Ryzen 7 1700 where the base clock is 3.00ghz, in the BIOS, all I had to do was set the CPU CLOCK RATIO to 3.1ghz, when I rebooted back to the BIOS I noticed that the voltage was high (around 1.2v), then tried to change the voltage of the PSTATE in the BIOS. And it worked. To decrease the max frequency from 3.1ghz, all I did was set the Pstate0 CPU frequency to 2.5ghz.
My Setup:
Pstate0: 2.5ghz at around 0.768v
Pstate1: 1.55ghz at around 0.612v
Core Performance Boost: Disabled
Global C6 State: Enabled (Reduces idle power usage)
SOC VOLTAGE: around 0.684v (Reduces idle power usage)
Ram Speed: 1333mhz (Reduces idle power usage)