CPU temp at 122c

Darron · 16 November 2021 08:49

CPU temp : WARNING: 122’C : 251’F (Reducing the life of your device)
I know this is wrong, the PC wouldn’t work if it was right. So how do I correct it?

I’m running x86 and it’s reported at MOTD.
neofetch is reporting it correctly at 24c

It’s a cosmetic thing so no big deal.
I know I can disable it in dietpi-banner, but I’d rather it was corrected.

TIA.
Daz.

 DietPi v7.8.2 : 09:53 - Tue 11/16/21
 ─────────────────────────────────────────────────────
 - Device model : Native PC (x86_64)
 - Uptime : up 52 minutes
 - CPU temp : WARNING: 122'C : 251'F (Reducing the life of your device)
 - FQDN/hostname : Server
 - LAN IP : 192.168.0.51 (eth0)
 - WAN IP : xx.xx.xx.xx England GB
 - Freespace (RootFS) : 153G
 - Freespace (userdata) : 153G
 - Weather (wttr.in) : Bradford, United Kingdom: 🌫  🌡️+9°C 🌬️↗11km/h
 - MOTD : Read more about the new DietPi-Dashboard:
          https://dietpi.com/docs/software/system_stats/#dietpi-dashboard

Joulinar · 17 November 2021 10:10

usually our script is just reading the temp from system sensor. Let’s have a look. Just copy the entire code block and have it executed

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

Darron · 17 November 2021 10:12

Results:

/sys/class/thermal/thermal_zone0/temp :
/sys/class/hwmon/hwmon0/temp1_input : 123000
/sys/class/hwmon/hwmon0/temp2_input : -62500
/sys/class/hwmon/hwmon0/temp3_input : 26000
/sys/class/hwmon/hwmon0/temp4_input : 113000
/sys/class/hwmon/hwmon0/temp5_input : 115000
/sys/class/hwmon/hwmon0/temp6_input : -128000
/sys/class/hwmon/hwmon0/temp7_input : 24000
/sys/class/hwmon/hwmon0/temp8_input : 0
/sys/class/hwmon/hwmon0/temp9_input : 0
/sys/class/hwmon/hwmon1/temp1_input : 24000
/sys/class/hwmon/hwmon1/temp2_input : 24000
/sys/class/hwmon/hwmon2/temp1_input :

Neofetch: CPU: AMD Ryzen 5 1600 (12) @ 3.2GHz [24.7°C]

Joulinar · 17 November 2021 10:16

interesting, all your sensor giving different temps, even negative one. If I’m not mistaken our script will use the first one available. Which would be

/sys/class/hwmon/hwmon0/temp1_input : 123000

MichaIng
pls correct me if I’m wrong

Darron · 17 November 2021 10:20

interesting, all your sensor giving different temps, even negative one. If I’m not mistaken our script will use the first one available. Which would be
/sys/class/hwmon/hwmon0/temp1_input : 123000
@MichaIng
pls correct me if I’m wrong

IIRC it was correct before I started installing apps.
It does look like #7 is the correct one.

MichaIng · 17 November 2021 15:19

Sadly this API isn’t used firmware wise in a consistent way, so we need to add special cases from time to time. Bad that it is an x86_64 system so we cannot simply check a different file based on the hardware ID only.

Which apps did you install which may have changed it? Is it possible that it actually was a recent kernel upgrade?

Btw here the current logic: https://github.com/MichaIng/DietPi/blob/733d81e/dietpi/func/dietpi-globals#L1701-L1720
/sys/class/hwmon/hwmon0/temp1_input is used because prior checked ones contain none of negative values.

Darron · 17 November 2021 15:29

Yeah it’s the previous X86 image, or at least 2 weeks old.
Freshly installed this weekend.

optional extras installed:

openSSH
Nload
Pi-Hole with DHCP
LASP
LAMP
Nextcloud

I think I installed lm-sensors and ran sensors-detect on this installation, but I could be wrong. I know I purged it all to check and there’s nothing left there.

MichaIng · 17 November 2021 16:25

Hmm, not sure whether lm-sensor can or does change anything in sysfs, but I would wonder if it did. Not sure how to handle yet, as other systems may have a wrong temperature at temp7_input or below hwmon1.

Darron · 17 November 2021 16:38

I’m just about to do a fresh install (from USB SSD to internal NVMe), nothing lost and this time I know it’s clean.

Darron · 17 November 2021 20:08

Whatever I did previously has been undone.

It’s working as it should again.

There is a slight discrepancy between neofetch and motd.
Neofetch is 10c lower, I can only assume this is MOTD reporting package temps, while neofetch is reporting core temps. This is normal.

Joulinar · 17 November 2021 20:25

We simply read the temperature from /sys/class/hwmon/hwmon0/temp1_input. That’s what is reported by your system. Nothing more. Probably the other tool using a different value.

MichaIng · 18 November 2021 16:07

Also note that core temperatures can change quite quickly, also when only running the commands to read the temperature. To reduce overhead, after neofetch try to immediately execute either:

cat /sys/class/hwmon/hwmon0/temp1_input

or

G_OBTAIN_CPU_TEMP

Darron · 18 November 2021 22:07

Thank you guys for trying to sort this out, but …

root@Server:~# cat /sys/class/hwmon/hwmon0/temp1_input
32850
root@Server:~# G_OBTAIN_CPU_TEMP
43
root@Server:~#

Two different commands two different temperatures, and that’s not counting nefetch which is reporting another:
CPU: AMD Ryzen 5 1600 (12) @ 3.200GHz [26.6°on]

Then I installed lm-sensors:

root@Server:~# cat /sys/class/hwmon/hwmon0/temp1_input
32850
root@Server:~# G_OBTAIN_CPU_TEMP
42
root@Server:~# sensors
iwlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +42.0°C

nvme-pci-0100
Adapter: PCI adapter
Composite:    +32.9°C

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +25.5°C
Tdie:         +25.5°C
CPU: AMD Ryzen 5 1600 (12) @ 3.200GHz [25.7°on]

It makes me curious though, how can I feed the Tctl or Tdie sensors back to your MOTD? So instead of 42c it reports Tdie?
I’m sorry for the hassle, it’s really not important, but it’s just a bit of an annoyance and it’d be nice to have some parity.

MichaIng · 19 November 2021 14:06

You can find the /sys file which matches this temperature and put it to the top of the list in the mentioned /boot/dietpi/func/dietpi-globals script. To update the function for the current shell session:

. /boot/dietpi/func/dietpi-globals

It seems like 42°C is the WiFi adapter? Hotter than the CPU, strange .

Darron · 19 November 2021 18:06

You can find the /sys file which matches this temperature and put it to the top of the list in the mentioned /boot/dietpi/func/dietpi-globals script. To update the function for the current shell session:
. /boot/dietpi/func/dietpi-globals
It seems like 42°C is the WiFi adapter? Hotter than the CPU, strange .

Want to hear something really strange? I’ve disabled it!

MichaIng · 20 November 2021 20:47

Confusing . I dream of a world where every kernel/firmware/manufacturer uses the same sysfs files to provide CPU temperatures, same as optionally GPU and mainboard chip temperatures, those for HDDs/storage etc . Not sure how to proceed with this. For x86 as said it is difficult/expensive to differentiate between individual hardware. Easiest would be to allow defining a custom sysfs path to read. I just don’t like that this would mean to run another sed on every function call. Probably we can load it as environment variable as part of dietpi-globals .

Darron · 4 August 2022 13:28

Sorry for digging this up again.
How do I setup the banner script to fetch this?
BTW even neofetch gets it wrong and tells me the CPU is at 92c at idle!

k10temp-pci-00c3
Adapter: PCI adapter
Tctl: +56.9°C
Tdie: +56.9°C

Darron · 4 August 2022 13:43

Thank you Michalng, all the information was there in your posts.
Sorted it

Device model : Native PC (x86_64)
Uptime : up 25 minutes
CPU temp : 63 °C / 145 °F : Running hot, not recommended

nano /boot/dietpi/func/dietpi-globals

                        local i afp_temperature=(

                                '/sys/class/hwmon/hwmon1/temp1_input' #My CPU Temp?

Joulinar · 4 August 2022 14:39

Well even if you solved it for now, the script will get overwritten on next update

Darron · 4 August 2022 14:59

that’s the reason I wrote it down, next time I can make a quick edit, done in 2 minutes.
and it might help someone else of course.