How does your CPU identify itself?

[ravenclaw900]

Hi everyone,
I'm currently working on rewriting a large section of DietPi-Dashboard. One of the goals of this rewrite is to show more accurate CPU temperature values. To do this, I would like to see how different CPUs identify themselves in the temperature interface.

Below is a small bash script that you can run. It will return a formatted list of everything that has a readable temperature on your system. If you can, please post the output of this script in the discussion, along with the CPU/SBC that it was run on. Note that it might return values that aren't for your CPU, and you can remove them if you'd like.

#!/bin/bash
for i in /sys/class/hwmon/hwmon*
do
    for j in temp{0..9}
    do
    [[ -f "$i/${j}_input" ]] || continue

    name=$(< "$i/name")

    [[ -f "$i/${j}_label" ]] && name+=" $(< $i/${j}_label)"
    [[ -f "$i/device/model" ]] && name+=" $(< $i/device/model)"

    [[ -f "$i/${j}_label" && -f "$i/device/model" ]] && name+=" $j"
    [[ ! -f "$i/${j}_label" && ! -f "$i/device/model" ]] && name+=" $j"

    echo $name
    done
done

Thanks for your help!

[ravenclaw900]

AMD Zen 3: k10temp Tctl
Intel 6th gen (coretemp Package id 0 is probably the general CPU temp):

pch_skylake temp1
coretemp Package id 0
coretemp Core 0
coretemp Core 1
coretemp Core 2
coretemp Core 3

RPi 4 and Zero W: cpu_thermal temp1

[MichaIng]

Since there is zero consistency about this and it can change between Kernel versions, are you sure that you want to maintain such for the dashboard? The G_OBTAIN_CPU_TEMP function of DietPi does it in a hybrid generic/specific way, not 100% reliable, but at least we react to reports when it changes on particular supported SBCs.

Best really would be to use a crate for this, i.e. let others do this maintenance efforts for a crate which does exactly only that. Ah we use already one, isn't it?

[ravenclaw900]

Generally, this will be handled by the sysinfo crate. It will get a list of all the things that show temperature, and will return a label for them similar to what the script above prints. What I'm trying to do here is get some devices that are known to be CPUs, and prefer them over other ones when finding temperature. If nothing can be found according to the preference, it will just use the first found temperature value.

This is already partially implemented in the dashboard due to ravenclaw900/DietPi-Dashboard#387, I just want to extend the list of known good CPU values.

[MichaIng]

With values you mean labels? That makes sense indeed, at least sometimes they have meaningful names.

The coretemp "packages" AFAIK are different CPUs (with each in case multiple cores) on the same board, resp. for setups like ARM big.LITTLE. And there may be an overall package/CPU temperature or it is just the average of all contained core temps, if each of them really has an own sensor. However, in this case I would stick with using the coretemp path. The way it is currently implemented, it picks the first package temp. Each of them has a matching hwmon entry, but when checking hwmon there is at least a chance for getting a false value while coretemp is assured to be about the CPUs.

[ravenclaw900]

While coretemp is guaranteed to be the CPU (or a specific core), it also only seems to exist on Intel x86_64 CPUs. coretemp will be one of the preferred CPU temperature identifiers, probably along with k10temp and anything containing cpu. I'm just gathering data here to see what labels are guaranteed/most likely CPUs, and which ones aren't.

It would be great if there was some sort of universal identification of what a specific device is (and in a way, there is one in /device/type, but it often doesn't exist). However, since that doesn't exist, this is what we're stuck doing. I figure that collecting data now and using it near the beginning is a better solution than just dealing with bug reports as they come along.

[MichaIng]

Jep, coretemp is Intel-only. Okay let's collect some data here. If we find some pattern, this would be helpful for dietpi-globals G_OBTAIN_CPU_TEMP as well.