[SOLVED] Software in Linux similar to Cpuid's CPU-Z?

budrz89 · 07-09-2022, 01:49 PM

Hi,

So I've tried some of the programs and recommendations in

https://www.linuxquestions.org/quest...or-etc-301253/

but it doesn't display the CPU voltage like CPU-Z does. I've tried CPU-X (a PKGBUILD in AUR), the sort of Linux version but it appears to be missing the voltage readings. Finally I've even tried lm_sensors as was done here:

https://forums.anandtech.com/threads...ltage.2325245/

but I couldn't get it to work. I'm not sure what to do or what I'm doing wrong.

My system is Artix Linux (runit) with the latest updates and my DE is openbox on a desktop computer. I do realize that there's gnome sensors as well but I don't know how to implement it in openbox. Also, hwinfo or dmidecode doesn't seem to give you the current voltage value, but maybe I'm wrong:

https://stackoverflow.com/questions/...n-linux-server

Any suggestions?

biker_rat · 07-10-2022, 08:56 AM

Artix is mod of archlinux so start here: https://wiki.archlinux.org/title/Lm_sensors

pinqvin · 07-10-2022, 12:09 PM

What about CPU-X?

Timothy Miller · 07-10-2022, 04:33 PM

Quote:

Originally Posted by pinqvin

What about CPU-X?

He specifically answered this in the original post. It doesn't have voltage monitoring, which is accurate, it does not have that functionality that he uniquely looking for.

Agreed on the first suggesting, lm_sensors package can usually be set up with most motherboards to monitor this.

budrz89 · 07-10-2022, 06:06 PM

Thanks guys I'll try lm_sensors again. Perhaps I'm overlooking something.

obobskivich · 07-10-2022, 07:28 PM

You may need to run 'sensors-detect' and let it go through all the various devices on your system one by one. That I'm aware of there is nothing directly equivalent to CPU-Z, but some applications can try to access most of the information that CPU-Z is bringing together, for example running conky and lm_sensors together (some example search results on the topic: https://bbs.archlinux.org/viewtopic.php?id=32400 https://bbs.archlinux.org/viewtopic.php?id=158103 http://blog.fraggod.net/2014/05/19/d...-in-conky.html). A lot of this will require hand-holding it along, as opposed to just running something like CPU-Z or AIDA64 as you can on Windows. Some things still do not work (for example there is no good software-based way, that I'm aware of, to get a linux box to spit out if it is running memory in single, dual, triple, etc channel - most of the proposed solutions online use dmidecode to check for the presence of >1 memory module and then blindly assume that will obviate interleaving being enabled). Also bear in mind - there's a decent bit of hand-holding taking place on the development of those Windows apps to deal with weird offsets and corner cases for real-life hardware - if you've ever played around with Speedfan in Windows you have probably noticed that as well. It may be the case that your specific hardware doesn't expose the information in a way that is standard/well understood which limits the ease of software 'just working' with it. Depending on the hardware you've got, it may have some OOB/IPMI interface that can display some of this kind of information if connected (this is very much a 'long shot' idea).

budrz89 · 07-10-2022, 07:44 PM

Success!

I wish I knew exactly what worked but I did the following:

Code:

# modprobe eeprom

Code:

$ yay -s it87-dkms-git

Code:

# sensors-detect

Most of the first few questions were the default except that

Code:

Q#4(ISA ports): Yes
Q#8-15 (AMDGPU's): Yes

followed by a

Code:

# sv restart lm_sensors

(restarting the lm_sensors service) in order to load the required modules which I found was the nct6775 module.

I'll have to admit that I'm not sure if the it87 install was necessary, but maybe it was.

Either way, now I can view the temperatures and voltages.

budrz89 · 07-11-2022, 12:07 PM

@obobskivich, I just seen your post and I appreciate your tips. I'll look into it.

I'm not sure how to interpret the results however:

Code:

# sensors
amdgpu-pci-0b00
Adapter: PCI adapter
vddgfx:        6.00 mV 
fan1:           0 RPM  (min =    0 RPM, max = 3300 RPM)
edge:         +34.0°C  (crit = +110.0°C, hyst = -273.1°C)
                       (emerg = +115.0°C)
junction:     +37.0°C  (crit = +110.0°C, hyst = -273.1°C)
                       (emerg = +115.0°C)
mem:          +38.0°C  (crit = +105.0°C, hyst = -273.1°C)
                       (emerg = +110.0°C)
PPT:           5.00 W  (cap = 186.00 W)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +36.9°C  (low  =  -5.2°C, high = +79.8°C)
                       (crit = +84.8°C)

nct6798-isa-0290
Adapter: ISA adapter
in0:                        1.08 V  (min =  +0.00 V, max =  +1.74 V)
in1:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                        3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                        3.30 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                      840.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                      1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                        3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                        3.31 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                      912.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                     304.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                     432.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                       1.04 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                     992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                     1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                        0 RPM  (min =    0 RPM)
fan2:                      843 RPM  (min =    0 RPM)
fan3:                        0 RPM  (min =    0 RPM)
fan4:                        0 RPM  (min =    0 RPM)
fan5:                     1315 RPM  (min =    0 RPM)
fan6:                        0 RPM  (min =    0 RPM)
fan7:                        0 RPM  (min =    0 RPM)
SYSTIN:                    +34.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
CPUTIN:                    +38.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
AUXTIN0:                   +26.0°C    sensor = thermistor
AUXTIN1:                   +48.0°C    sensor = thermistor
AUXTIN2:                   +49.0°C    sensor = thermistor
AUXTIN3:                   +26.0°C    sensor = thermistor
PECI Agent 0 Calibration:  +38.5°C  
SMBUSMASTER 1:             +58.5°C  
PCH_CHIP_CPU_MAX_TEMP:      +0.0°C  
PCH_CHIP_TEMP:              +0.0°C  
TSI0_TEMP:                 +40.6°C  
TSI1_TEMP:                 +58.8°C  
intrusion0:               ALARM
intrusion1:               ALARM
beep_enable:              disabled

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +33.0°C  

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +41.0°C  
Tccd1:        +52.5°C

Are any of the "in0-14" or "vddgfx" recording my CPU voltage? I don't see a listing for my CPU voltage. I forgot to mention that my motherboard is X570-P. There should be additional support for my board:

https://bugzilla.kernel.org/show_bug.cgi?id=204807#c218

obobskivich · 07-11-2022, 01:43 PM

This is what I meant by 'will take some hand-holding' - it is indeed getting all of the sensors out, but you have to figure out what's what without the help of Asus' software papering over this.

Some observations:
- Everything under 'amdgpu-pci-0b00' will be a graphics adapter of some kind - it's an AMD-based chip so if you want more control there, the application CoreCtrl is the choice (https://gitlab.com/corectrl/corectrl). This is very typical for an AMD GPU in terms of what it offers - 'edge' is the temperature sensor to watch for thermal performance there, and is what the fan control will be based on ('junction' will report higher values, and is (per AMD's description) not a singular sensor, but instead a spot-check of whatever the hottest internal report from the GPU is during that interval (which, if I remember right, can include power components) - depending on which specific generation/model of GPU you have will tell you exactly what is 'safe' for this value (you'll have to google this), but values over 100* C are not uncommon - if this exceeds its trip point it will trigger a core slowdown on the GPU, and that's all this sensor is meant to do).

- k10temp-pci-00c3 is your CPU's thermal sensors - I'm not sure how this works on newer AMD CPUs, but historically these sensors don't track a temperature that has a basis in physical reality, but instead show some kind of "AMD degrees" (the explanation has always been that they're kind of a 'pass/fail' sensor - it doesn't matter how accurate or inaccurate it is as long as it prevents over-heating, which it does), so take those values with a grain of salt vs 'real' temperatures. Consider the difference to the 'CPUTIN' sensor from the motherboard (which is likely a diode on the socket).

- The motherboard appears to be exposing a lot of sensors from nct6798, and there are likely duplicates (I'm guessing in1, in4, in6, and in14 may be the same thing, ditto for in2 and in7) - I would probably start by going into the system's UEFI and looking at whatever voltage/temperature readouts are there, getting an idea of what the board 'officially' is trying to report, and then correlate that to values you can get from lm_sensors (for example I'm guessing in3 or in8 is probably tracking a 3.3VDC input from the system power supply; some others may be trying to track other PSU voltage rails, or output voltages to things like PCIe, RAM, SoC/Uncore, etc - there may also be offsets not being applied so the values may be inaccurate vs actual). In the running system you may also try viewing sensors with watch (with the n1 flag), and loading the CPU up (the 7zip benchmark is an easy way to do this) and seeing what, if anything, changes - it may give you some sense of the relationship between those values.

budrz89 · 07-12-2022, 02:42 PM

Thanks for the tips and observations @obobskivich !

I will try out some of your suggestions.

budrz89 · 07-12-2022, 04:04 PM

Comparing what watch gave me and what I've found in the BIOS, I'm guessing in0 is the VDDCR CPU voltage. I had to use "cwatch" script because the output was pretty long:

https://serverfault.com/questions/50...rsion-of-watch

Anyway this will probably be the closest that one can get to CPU-Z: a watch script + sensors.

Thanks everyone for the help.

EDIT: There is a nice program from the AUR called hardinfo-gtk3 that does this and more:

https://aur.archlinux.org/packages/hardinfo-gtk3/