(Beelink) AMD AI9HX370 wrong temperature with cpu command (htop is OK)

Community Tutorials
1

To get the right temperature for the Beelink AIHX370 with the cpu (/boot/dietpi/dietpi-cpuinfo) command you can add an extra line to /boot/dietpi/func/dietpi-globals see:

Array to store possible locations for temp read

                    local i afp_temperature=(

                            '/sys/class/hwmon/hwmon2/temp1_input' # Beelink AI9HX370
                            '/sys/devices/platform/coretemp.[0-9]/hwmon/hwmon[0-9]/temp[1-9]_input' # Intel Mini PCs: https://github.com/MichaIng/DietPi/issues/3172, https://github.com/MichaIng/DietPi/issues/3412
                            '/sys/class/thermal/thermal_zone0/temp'
                            '/sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/temp1_input'
                            '/sys/class/hwmon/hwmon0/device/temp_label'
                            '/sys/class/hwmon/hwmon0/temp2_input'
                            '/sys/class/hwmon/hwmon0/temp1_input' # Odroid C1 Armbian legacy Linux 5.4.40: https://dietpi.com/phpbb/viewtopic.php?p=24860#p24860
                            '/sys/class/thermal/thermal_zone1/temp' # Roseapple Pi, probably OrangePi's: https://dietpi.com/phpbb/viewtopic.php?t=8677
                            '/sys/class/hwmon/hwmon[0-9]/temp[1-9]_input'
                    )
2

ping @MichaIng

3

Yeah not so much we can do about it if some box is using those sysfs APIs in a weird way. htop uses the sensors utility to show temperatures, if installed, but our cpu command works without any external utility, solely relying on sysfs entries. For SBCs with individual hardware IDs, we can make special cases, but for x86_64 we have no reasonable way to differentiate between hardware. Intel NUC boxes were a similar issue, but they use the coretemp API quite consequently.

Since the hwmon sysfs entries are looped through sequentially in the end, which sysfs entry is read before that, which contains a false value, or something not related to the CPU at least?

4

The first hit was /sys/class/thermal/thermal_zone0/temp which returned 20000 (20 degrees)

The sensors command returned this:
k10temp-pci-00c3
Adapter: PCI adapter
Tctl: +51.4°C

acpitz-acpi-0
Adapter: ACPI interface
temp1: +20.0°C

iwlwifi_1-virtual-0
Adapter: Virtual device
temp1: N/A

nvme-pci-6100
Adapter: PCI adapter
Composite: +36.9°C (low = -0.1°C, high = +82.8°C)
(crit = +84.8°C)
Sensor 1: +36.9°C (low = -273.1°C, high = +65261.8°C)

5

Okay, so /sys/class/thermal/thermal_zone0/temp is used by some dummy sensor it seems. I wished there was a standard to use thermal_zone0 or /sys/class/hwmon/hwmon0/temp1_input for the CPU temperature, in case of the first core/group/sensor.

I guess to cover such cases, we should add an option to select a particular sysfs thermal node.

6

That’s maybe a good idea! What is the idea? To add this to the dietpi-config script or add a new dietpi-cpu_temp script?

7

Since currently, obtaining the temperature itself it is just a shell function G_OBTAIN_CPU_TEMP, probably just a new function with optional argument(s) to list and select the available sysfs nodes. Or merging it into the /boot/dietpi/dietpi-cpuinfo, to not bloat the shell environment more, not sure yet.