Open tiburcillo opened 3 years ago
@IanSteveC I don't know then. A quick search shows that CPU VDDCR_SOC is the voltage going to the pins. IIRC, with my offset, the sensor would show 1.4V while SVI2 would show 1.325V. Might be something similar going on with yours. @hattedsquirrel Wouldn't the apparent lower current influence the voltage?
From what I can suss from the posts at OCN for the two Ryzen memory OC threads I read every day, it seems that AMD has pushed up the SoC voltage to a nominal 1.2V to be able to support the Ryzen 5000 cpus with their 4000Mhz memory capabilities.
If you were to drop your 3900X back in, I'm positive the SoC voltage would drop back down to the standard 1.09V level without you making a single change in the BIOS.
This post has a lot of great information regarding max voltages for Vermeer from the expert on the subject. https://www.overclock.net/threads/official-amd-ryzen-ddr4-24-7-memory-stability-thread.1628751/post-28749850
@fr33-man No. Under-reporting the current to the SoC does not cause over-reporting of the SoC voltage. Sure, a board-manufacturer could, in theory, implement both independently, but that would defeat the primaray reason for under-reporting the current. Anyway, concerning @IanSteveC's original question I think we can say: Yes, a reading of 1.20V is not unusual. And since he saw the same number in Windows and the BIOS, we can conclude that the value is read corectly from the register. If the question continues to whether that reported value matches the actual voltage, I see two ways to find out: 1) Do a physical measurement. Thats the only way to know for sure. 2) If the first option is not possible, one could still ask the SMU. It offers several measurements from within the CPU package, even covering some on-die post-regulators. One had to trust the SMU firmware in that case, but so far I haven't heared any rumours that board manufacturers tinkered with that.
@IanSteveC
I also noticed that in the BIOS HW monitor section, it lists two SOC values, one around 1.2 that i see from >software "CPU VDDCR_SOC", and another that matches my BIOS setting under the label >"PREM_VDDCR_SOC"
The SoC actually gets 9 voltages rails from the socket. The most important ones are VDDCR_SOC (supplied by the big SOC relgulator), VDDIO_MEM and VDDP. VDDP per default is around 0.9V. It is well possible, that PREM_VDDCR_SOC actually refers to this power rail, but I'm not sure about that nomenclature.
@KeithMyers Yes, that matches my experiments and with the overclocking reports I read. The Ryzen 5000 CPUs are rated for 3200MHz memory speed according to the official AMD page. In my experience the SoC voltage defaults to 1.0V for 3200MHz and below. Above that it defaults to 1.2V. Thats why I thought it might have to do with the memory speed.
I have my memory pushed to 3600Mhz 1:1:1 and the SoC voltage as stayed the same as it is at 1.09V at stock 3200Mhz.
I have applied https://crazy.dev.frugalware.org/ZEN3-test4.patch and modified zenmonitor as suggested here: https://github.com/ocerman/zenmonitor/issues/36 - but I'm not getting voltage and temperature values, just Package Power, Core Effective Frequency, Core Power and Core Frequency. I have Ryzen 9 5950X, and I see somebody with 5900X here https://github.com/ocerman/zenmonitor/issues/36 have Core Voltage and Temperature values. I tried rebooting. I'm running zenmonitor with root privileges. Any ides what could be wrong?
The values you are missing are read from the zenpower module. What is the output of sensors zenpower-*
?
sensors zenpower-*
Specified sensor(s) not found!
But zenpower module is loaded:
lsmod | grep zenpower
zenpower 16384 0
Is there an additional step to get sensors working besides compiling and loading the module?
Is there an additional step to get sensors working besides compiling and loading the module?
No, usually not.
If you have ZEN3-test4.patch applied and insmod
the freshly built module it should give you a line in dmesg like "using ZEN2 calculation formula". It should also create a structure in /sys/class/hwmon/hwmon[num]/
. On my system it looks like this:
root@ryzen:~# ls /sys/class/hwmon/hwmon3/
curr1_input device name power2_label temp2_input temp4_label
curr1_label in1_input power subsystem temp2_label uevent
curr2_input in1_label power1_input temp1_input temp3_input
curr2_label in2_input power1_label temp1_label temp3_label
debug_data in2_label power2_input temp1_max temp4_input
root@ryzen:~# cat /sys/class/hwmon/hwmon3/name
zenpower
root@ryzen:~# cat /sys/class/hwmon/hwmon3/power2_label
SVI2_P_SoC
> sudo rmmod zenpower
> lsmod | grep zenpower # Returns nothing which means zenpower module is removed
> make clean && make # Rebuild the module from scratch
> sudo insmod zenpower.ko # Nothing appears in dmesg after running this command but the module is inserted successfully
> lsmod | grep zenpower
zenpower 16384 0
> ls /sys/class/hwmon/ # No zenpower hwmon present; hwmon0 is from k10temp
hwmon0
> cat /sys/class/hwmon/hwmon0/name
k10temp
So in my case it does not create the structure in there, and there is nothing in dmesg when I insmod the module (or when I modprobe it after installing).
I'm using Ubuntu Studio 20.10 with its default kernel (5.8.0-48-lowlatency). I'm not sure how to debug this... The module is definitely loaded and it is of the right version:
> ls /sys/module/zenpower/
coresize drivers holders initsize initstate notes refcnt sections srcversion taint uevent version
> cat /sys/module/zenpower/version
0.1.12-ZEN3-test4
Just to be sure I rebooted again, nothing changed. I do not have any experience with debugging Linux modules. I would be grateful if somebody could give a suggestion what to do next.
Make sure that you don't have the k10temp module loaded. To me it sounds like that is your problem.
If unsure, just unload it with modprobe -r k10temp
before loading zenpower.
And for the future (if you want to use zenpower), put it into the blacklist.
Thank you, now everything working as expected. Not sure how I managed to miss this step.
Is patch still required 5600x? I'm running Linux 5.11.8, and was only seeing 2 temperatures, which was disappointing. After searching around, I've found that Zen 3 is supposed to work with zenpower, so I installed that, but now just see Tdie and Tctl, which both are the same value, and I'm not even sure if I trust them yet. Is this issue still not fixed in "master" branch? Is it fixed in another branch, or do I need to apply this ZEN3-test4.patch for it to work? What's holding up getting this fix merged into a branch? Does it need more testing or code review? How can I help? I'd like to have valid temperature and voltage readings. (And fan speed too, but I guess I need to solve that in another place...)
To make this work properly, I have applied the following patch to zenpower (I do not know why it still is not committed yet to the master):
https://crazy.dev.frugalware.org/ZEN3-test4.patch
And also I had to apply the patch from https://github.com/ocerman/zenmonitor/issues/36#issue-772578612 to zenmonitor to add support for Zen 3 family. I also applied https://github.com/ocerman/zenmonitor/pull/32.patch (fix order of tDie and tCtl to reflect order of zenpower drive) but for me tDie and tCtl are always the same anyway, so it did not make noticeable difference in my case. I do not know if they are supposed to be different, as far as I can tell there is no alternatives to zenpower, so I do not have other ways to check these values (Linux is my only OS).
Unloading and blacklisting k10temp module is also important step, zenpower will not work properly while it is loaded.
Ideally, there should be precompiled debs with installation script, but no one have found a time to create them yet.
For now I can share only deb file for zenmonitor (patched for Zen 3 support and compiled in Ubuntu 20.10): http://dragon.studio/2021/04/zenmonitor_2021-04-04-1_all.deb Creating deb for zenpower is more complicated.
Using Lissanro latest ZEN3-test4.patch on 5950x, works like a charm on ubuntu 21.04, maybe ocerman would like to see pull request ?
zenpower3 and zenmonitor3 are actively maintained forks of this project that have Zen 3 support.
@Ta180m , thanks for keeping this nice tool alive!
Shame that zenpower3 fork is closed and read-only now. No support for kernel 6.0+ which does not compile and run anymore.
The aur-package has retargeted against this repo https://git.exozy.me/a/zenpower3
There's not much more commits over there, but arch haven't yet switched to 6.0 so hopefully it will get fixed if there are any issues.
You could preemptive make a ticket if 6.0 is broken
Would it be a lot of work to add support for the Zen3 family? I love zenpower on my 2700x, would be cool if my 5600x would also be supported.
Thanks, t