DietPi-Globals | G_OBTAIN_CPU_TEMP: Add /sys/devices/platform/coretemp*

[BrownC0de]

Creating a bug report/issue

Required Information

• DietPi version | cat /DietPi/dietpi/.version
  G_DIETPI_VERSION_CORE=6
  G_DIETPI_VERSION_SUB=26
  G_DIETPI_VERSION_RC=3
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version
  10.1

• Kernel version | uname -a
Linux MDNS 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 GNU/Linux

• SBC device | echo $G_HW_MODEL_DESCRIPTION or (EG: RPi3)
  x86 GIGABYTE BRIX GB-XM12-3227

• Power supply used | (EG: 5V 1A RAVpower)
  This is ok

• SDcard used | (EG: SanDisk ultra)
  none (SSD M2)

Additional Information (if applicable)

• Software title | (EG: Nextcloud)
  irrelevant
• Was the software title installed freshly or updated/migrated?
  freshly
• Can this issue be replicated on a fresh installation of DietPi?
  Yes

Extra details

I'm sorry for my english, it's all google
When connecting via ssh, i see the following information:

• Device model : Native PC (x86_64)
• CPU temp : 28'C : 82'F (Who put me in the freezer!)
  That is, the temperature of the CPU is not displayed correctly and I have certain experiences that at prismatic values the cooling fan does not turn on.

If you enter "sensors" to the command line, it displays the following information, which is more like the truth.
`root@MDNS:~# sensors
acpitz-acpi-0
Adapter: ACPI interface
temp1: +27.8°C (crit = +106.0°C)
temp2: +29.8°C (crit = +106.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +58.0°C (high = +87.0°C, crit = +105.0°C)
Core 0: +58.0°C (high = +87.0°C, crit = +105.0°C)
Core 1: +57.0°C (high = +87.0°C, crit = +105.0°C)
`
So the default information on the temperature he takes is not from the right place?
How can I correct the correct conclusion?

[MichaIng]

@IV711
Many thanks for your report.

Can you please paste the following:

for i in /sys/class/thermal/thermal_zone[0-9]/temp /sys/class/hwmon/hwmon[0-9]/temp[0-9]_input /sys/devices/platform/coretemp.[0-9]/hwmon/hwmon[0-9]/temp[0-9]_input
do
[[ -e $i ]] && echo "$i : $(<$i)"
done

• Lets see which generic thermal zone or hwmon driver is used.
• We do not check the last one, but from your sensors output it looks like it is the correct one, also based on the same we most likely should check this with highest priority.

[BrownC0de]

Here's what I got:

/sys/class/thermal/thermal_zone0/temp : 27800
/sys/class/thermal/thermal_zone1/temp : 29800
/sys/class/thermal/thermal_zone2/temp : 57000
/sys/class/hwmon/hwmon0/temp1_input : 27800
/sys/class/hwmon/hwmon0/temp2_input : 29800
/sys/class/hwmon/hwmon1/temp1_input : 57000
/sys/class/hwmon/hwmon1/temp2_input : 57000
/sys/class/hwmon/hwmon1/temp3_input : 57000

[MichaIng]

@IV711
Okay, so its thermal_zone2 and hwmon1 in your case. Hmm, in most cases on x86 its thermal_zone0 and hwmon0, not sure how to derive that as a generic approach. For SBC models, which all have a unique DietPi HW ID, we can use specific sysfs files to read from, but all x86_64 PCs share the same ID "21", so not trivial to apply device specific read rules there.

Does the following exist and perhaps contain a different file structure?

ls -Al /sys/devices/platform/coretemp*

[BrownC0de]

Does the following exist and perhaps contain a different file structure?

root@MDNS:/# ls -Al /sys/devices/platform/coretemp*
total 0
lrwxrwxrwx 1 root root    0 Oct 18 15:56 driver -> ../../../bus/platform/drivers/coretemp
-rw-r--r-- 1 root root 4096 Oct 18 15:56 driver_override
drwxr-xr-x 3 root root    0 Oct 15 22:54 hwmon
-r--r--r-- 1 root root 4096 Oct 18 15:56 modalias
drwxr-xr-x 2 root root    0 Oct 18 15:56 power
lrwxrwxrwx 1 root root    0 Oct 15 22:54 subsystem -> ../../../bus/platform
-rw-r--r-- 1 root root 4096 Oct 15 22:54 uevent

[MichaIng]

@IV711
Ah there it is, looks like this is the structure:

for i in /sys/devices/platform/coretemp*/hwmon/hwmon*/temp*
do
[[ -e $i ]] && echo "$i : $(<$i)"
done

[BrownC0de]

`> do

[[ -e $i ]] && echo "$i : $(<$i)"
done
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp1_crit : 105000
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp1_crit_alarm : 0
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp1_input : 57000
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp1_label : Package id 0
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp1_max : 87000
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp2_crit : 105000
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp2_crit_alarm : 0
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp2_input : 57000
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp2_label : Core 0
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp2_max : 87000
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp3_crit : 105000
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp3_crit_alarm : 0
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp3_input : 56000
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp3_label : Core 1
/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp3_max : 87000
`

[MichaIng]

/sys/devices/platform/coretemp.0/hwmon/hwmon1/temp1_input : 57000

That's it, Okay so the coretemp driver indeed only lists CPU temps and if it exists, it should be read in the first place, skipping the other files. Will implement this later.

[BrownC0de]

Thx

[BrownC0de]

Are these changes included in DietPi v6.28.0? Does not work

[MichaIng]

@IV711
Sorry I did not yet implement them, as v6.27 already grew quite much and needed to be released and v6.28 was a quick hotfix only.

I'm currently redoing all our images and start new coding and feature implementation afterwards.

[MichaIng]

@IV711
Finally done: 42bc75f
Changelog: e914391

[GvY85]

This seems to work in 6.29 beta for Intel N4200 UP-Squared board