[BUG] CPU Graph shows 0°C Temperature (AMD Ryzen)

[lodriguez]

Current Behavior

CPU Graph shows 0°C temperature

Expected Behavior

Show the actual temperature

Steps To Reproduce

AMD Ryzen 5800X3D Asus Rog Strix B550-F gaming (nct6775)

Screenshots

https://i.imgur.com/c9QEOp7.png

Logs

-

Versions

- Widget: 3.0.0-RC1
- KDE Plasma: 6.0.3
- KDE Framework: 6.1.0

Additional context

It probably just uses the wrong sensor. Would be nice to have an "advanced option" where we could select a sensor.

[orblazer]

Hello, Currently i use Maximum CPU Temperature on All CPU but maybe you haven't enable temps or something else.

1. Could you check on System Monitor app what sensors you have for CPU temperatures ?
2. Could you run sensors cmd and past the result ?

Thanks.

[lodriguez]

I personally use zenpower, but that isn't in the Kernel. TS10_TEMP from nct6775 would be the desired sensor. It's the same as k10temp or Tdie from zenpower.

sensors.txt

[orblazer]

Hum, Can you check if you have some sensors visible in System Monitor app ? if not i think i need to make some big changes to support that kind of package.

[lodriguez]

What do you mean? Everything in sensors is visible in System Monitor.

[orblazer]

Sorry i have totally forgeot to tell you the step you can follow :facepalm:

This is the step for retrieve sensors for temperature :

1. Create an new page in app
2. search different temperature related sensors in CPU section
3. save the page with select sensors
4. share the file of that page (stored in ~/.local/share/plasma-systemmonitor/)

[lodriguez]

That's the problem, everything in the CPU Section reports 0°C. That's why I use the chip on the Mainboard (nct6775). Some Asus board have this kind of behaviour. Asus uses asus-wmi-sensors, it87 or nct6775. Some boards still report using k10temp others don't…

[orblazer]

Oh ok, so i need to make an fallback and make something like i have done for network.

Could you past what you have when you run sensors -j '*-isa-*' ? I have that with an I7-7700 and board Z170M-D3H :

{
   "coretemp-isa-0000":{
      "Adapter": "ISA adapter",
      "Package id 0":{
         "temp1_input": 34.000,
         "temp1_max": 80.000,
         "temp1_crit": 100.000,
         "temp1_crit_alarm": 0.000
      },
      "Core 0":{
         "temp2_input": 29.000,
         "temp2_max": 80.000,
         "temp2_crit": 100.000,
         "temp2_crit_alarm": 0.000
      },
      // ...
   }
}

So i think i need to check if Package id 0 exist and fallback to something else (the else is the why i ask you to past the output :wink:).

[BanditSan]

Is it possible to implement check if zenpower3 module is loaded and use temp values from that? Or maybe add option in CPU settings. I like use zenpower instead of ISA cause it also reports power usage.

zenpower output section in sensors

zenpower-pci-00c3
Adapter: PCI adapter
SVI2_Core:     1.44 V  
SVI2_SoC:      1.14 V  
Tdie:         +40.0°C  (high = +95.0°C)
Tctl:         +40.0°C  
SVI2_P_Core:  13.26 W  
SVI2_P_SoC:    2.02 W  
SVI2_C_Core:   9.22 A  
SVI2_C_SoC:    1.76 A

If need any more info can post it also

[orblazer]

Ok so the name is not something like coretemp-isa-xxxx so i think if only zenpower currently throw that bug we can simply add an option on CPU to pass in zenpower (or i can do automatically).

Could you tel me what is the output of sensors -j 'zenpower-pci-*' (you can trunk it like i have done in my last comment :wink:), the output in json format is more easier to me to to implement in code.

[BanditSan]

I think problem is for systems that do not have zenpower module. Coretemp on Intel cpu's will have name like coretemp-isa-xxxx. Zenpower name is zenpower-pci-xxxx and even last 4 letters might be same on different cpu's. If you compare my sensors output and @lodriguez output it's zenpower-pci-00c3. He has 5800X3D and i have 5700G. But i guess safest is go zenpower-pci-xxxx name

sensors -j 'zenpower-pci-*'

```json { "zenpower-pci-00c3":{ "Adapter": "PCI adapter", "SVI2_Core":{ "in1_input": 1.438 }, "SVI2_SoC":{ "in2_input": 1.144 }, "Tdie":{ "temp1_input": 46.000, "temp1_max": 95.000 }, "Tctl":{ "temp2_input": 46.000 }, "SVI2_P_Core":{ "power1_input": 16.981 }, "SVI2_P_SoC":{ "power2_input": 3.029 }, "SVI2_C_Core":{ "curr1_input": 11.858 }, "SVI2_C_SoC":{ "curr2_input": 2.648 } } } ```

Without zenpower CPU temp provided by k10temp upstream kernel module. On my system it is acting weird and do not appear in sensors unless i load module with force=1 option.

sensors -j 'k10temp-pci-*'

```json { "k10temp-pci-00c3":{ "Adapter": "PCI adapter", "Tctl":{ "temp1_input": 39.625 } } } ```

That's the problem, everything in the CPU Section reports 0°C. That's why I use the chip on the Mainboard (nct6775). Some Asus board have this kind of behaviour. Asus uses asus-wmi-sensors, it87 or nct6775. Some boards still report using k10temp others don't…

nct6775 is kernel module for motherboards sensor not CPU's. Name in sensors will depend what sensors chip is on the board.

nct6775: Found NCT6798D or compatible chip at 0x2e:0x290

Me and @lodriguez we both have Asus mb just different model so chip is same. But for diferent board manufacturer name might be something like nctxxxx-isa-xxx or even *-isa-xxx

sensors -j 'nct6798-isa-*'

```json { "nct6798-isa-0290":{ "Adapter": "ISA adapter", "in0":{ "in0_input": 0.536, "in0_min": 0.000, "in0_max": 1.744, "in0_alarm": 0.000, "in0_beep": 0.000 }, "in1":{ "in1_input": 1.000, "in1_min": 0.000, "in1_max": 0.000, "in1_alarm": 1.000, "in1_beep": 0.000 }, "in2":{ "in2_input": 3.376, "in2_min": 0.000, "in2_max": 0.000, "in2_alarm": 1.000, "in2_beep": 0.000 }, "in3":{ "in3_input": 3.312, "in3_min": 0.000, "in3_max": 0.000, "in3_alarm": 1.000, "in3_beep": 0.000 }, "in4":{ "in4_input": 0.992, "in4_min": 0.000, "in4_max": 0.000, "in4_alarm": 1.000, "in4_beep": 0.000 }, "in5":{ "in5_input": 0.920, "in5_min": 0.000, "in5_max": 0.000, "in5_beep": 0.000 }, "in6":{ "in6_input": 0.248, "in6_min": 0.000, "in6_max": 0.000, "in6_alarm": 1.000, "in6_beep": 0.000 }, "in7":{ "in7_input": 3.376, "in7_min": 0.000, "in7_max": 0.000, "in7_alarm": 1.000, "in7_beep": 0.000 }, "in8":{ "in8_input": 3.296, "in8_min": 0.000, "in8_max": 0.000, "in8_alarm": 1.000, "in8_beep": 0.000 }, "in9":{ "in9_input": 1.808, "in9_min": 0.000, "in9_max": 0.000, "in9_alarm": 1.000, "in9_beep": 0.000 }, "in10":{ "in10_input": 0.640, "in10_min": 0.000, "in10_max": 0.000, "in10_alarm": 1.000, "in10_beep": 0.000 }, "in11":{ "in11_input": 2.048, "in11_min": 0.000, "in11_max": 0.000, "in11_alarm": 1.000, "in11_beep": 0.000 }, "in12":{ "in12_input": 1.032, "in12_min": 0.000, "in12_max": 0.000, "in12_alarm": 1.000, "in12_beep": 0.000 }, "in13":{ "in13_input": 0.360, "in13_min": 0.000, "in13_max": 0.000, "in13_alarm": 1.000, "in13_beep": 0.000 }, "in14":{ "in14_input": 0.264, "in14_min": 0.000, "in14_max": 0.000, "in14_alarm": 1.000, "in14_beep": 0.000 }, "fan1":{ "fan1_input": 791.000, "fan1_min": 0.000, "fan1_alarm": 0.000, "fan1_beep": 0.000, "fan1_pulses": 2.000 }, "fan2":{ "fan2_input": 1032.000, "fan2_min": 0.000, "fan2_alarm": 0.000, "fan2_beep": 0.000, "fan2_pulses": 2.000 }, "fan3":{ "fan3_input": 846.000, "fan3_min": 0.000, "fan3_alarm": 0.000, "fan3_beep": 0.000, "fan3_pulses": 2.000 }, "fan4":{ "fan4_input": 877.000, "fan4_min": 0.000, "fan4_alarm": 0.000, "fan4_beep": 0.000, "fan4_pulses": 2.000 }, "fan5":{ "fan5_input": 0.000, "fan5_min": 0.000, "fan5_alarm": 0.000, "fan5_beep": 0.000, "fan5_pulses": 2.000 }, "fan6":{ "fan6_input": 0.000, "fan6_min": 0.000, "fan6_alarm": 0.000, "fan6_pulses": 2.000 }, "fan7":{ "fan7_input": 996.000, "fan7_min": 0.000, "fan7_pulses": 2.000 }, "SYSTIN":{ "temp1_input": 30.000, "temp1_max": 80.000, "temp1_max_hyst": 75.000, "temp1_crit": 125.000, "temp1_alarm": 0.000, "temp1_type": 4.000, "temp1_offset": 0.000, "temp1_beep": 0.000 }, "CPUTIN":{ "temp2_input": 31.500, "temp2_max": 80.000, "temp2_max_hyst": 75.000, "temp2_crit": 125.000, "temp2_alarm": 0.000, "temp2_type": 4.000, "temp2_offset": 0.000, "temp2_beep": 0.000 }, "AUXTIN0":{ "temp3_input": 85.000, "temp3_max": 80.000, "temp3_max_hyst": 75.000, "temp3_crit": 125.000, "temp3_alarm": 1.000, "temp3_type": 4.000, "temp3_offset": 0.000, "temp3_beep": 0.000 }, "AUXTIN1":{ "temp4_input": 47.000, "temp4_max": 80.000, "temp4_max_hyst": 75.000, "temp4_crit": 125.000, "temp4_alarm": 0.000, "temp4_type": 4.000, "temp4_offset": 0.000, "temp4_beep": 0.000 }, "AUXTIN2":{ "temp5_input": -62.000, "temp5_max": 80.000, "temp5_max_hyst": 75.000, "temp5_crit": 100.000, "temp5_alarm": 0.000, "temp5_type": 4.000, "temp5_offset": 0.000, "temp5_beep": 0.000 }, "AUXTIN3":{ "temp6_input": 80.000, "temp6_max": 80.000, "temp6_max_hyst": 75.000, "temp6_crit": 100.000, "temp6_alarm": 1.000, "temp6_type": 4.000, "temp6_offset": 0.000, "temp6_beep": 0.000 }, "AUXTIN4":{ "temp7_input": 30.000, "temp7_max": 80.000, "temp7_max_hyst": 75.000, "temp7_crit": 100.000, "temp7_alarm": 0.000, "temp7_beep": 0.000 }, "PECI Agent 0 Calibration":{ "temp8_input": 43.000, "temp8_max": 80.000, "temp8_max_hyst": 75.000, "temp8_beep": 0.000 }, "PCH_CHIP_CPU_MAX_TEMP":{ "temp9_input": 0.000 }, "PCH_CHIP_TEMP":{ "temp10_input": 0.000 }, "PCH_CPU_TEMP":{ "temp11_input": 0.000 }, "PCH_MCH_TEMP":{ "temp12_input": 0.000 }, "TSI0_TEMP":{ "temp13_input": 54.000 }, "intrusion0":{ "intrusion0_alarm": 1.000, "intrusion0_beep": 0.000 }, "intrusion1":{ "intrusion1_alarm": 1.000, "intrusion1_beep": 0.000 }, "beep_enable":{ "beep_enable": 0.000 } } } ```

Ok so the name is not something like coretemp-isa-xxxx so i think if only zenpower currently throw that bug we can simply add an option on CPU to pass in zenpower (or i can do automatically).

Auto or option is up to you but it's always nice to have more options :) On Arch if you install zenpower-dkms package it blacklists upstream k10temp module from loading. Might be similar on other distros. For auto i guess 1st check for zenpower, 2nd for k10temp and maybe as 3rd option go for MB sensor. MB sensor is a bit unreliable and reports lower values compared to zenpower or k10temp and as mentioned above naming might be all over the place depending on the MB.

[orblazer]

Thank for all informations,

And in finally i can simply fallback to zenpower if the official sensor (cpu/all/maximumTemperature) return null value due it's currently only support coretemp and k10temp (src: https://invent.kde.org/plasma/ksystemstats/-/blob/master/plugins/cpu/linuxcpuplugin.cpp?ref_type=heads#L162).

I think is useless to add complexity to that, and i don't see how can have none of zenpower or k10temp enabled.

[BanditSan]

I guess plasma supports only official coretemp and k10temp modules from kernel. zenpower and zenpower3 are 3rd party modules. There was discussion about upstreaming zenpower3 code to kernel, but it never happened. zenpower3 for me much better module since it provides more info fompared to k10temp

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

zenpower-pci-00c3
Adapter: PCI adapter
SVI2_Core:     1.43 V  
SVI2_SoC:      1.14 V  
Tdie:         +44.8°C  (high = +95.0°C)
Tctl:         +44.8°C  
SVI2_P_Core:  15.02 W  
SVI2_P_SoC:    2.36 W  
SVI2_C_Core:  10.54 A  
SVI2_C_SoC:    2.06 A

[orblazer]

Hello, Could you try the fix with the unreleased version ?

For that you have to download repo and choose 1 of bellow options :

• run ./scripts/test.sh (require have plasma-sdk installed)
• copy package folder in ~/.local/share/plasma/plasmoids/org.kde.plasma.resources-monitor/, and restart plasma shell (with killall plasmashell; kstart plasmashell or logout/login)

Thanks.

[BanditSan]

Something is still not working right. Temp shows up for second after enable and goes back to 0

Short demo

https://github.com/orblazer/plasma-applet-resources-monitor/assets/6743235/5237456f-a0b1-439d-8314-f93ff424773b

[orblazer]

if you keep it enabled it's stuck to 0 ? I think i have an issue with my fallback detection method, or it's because "official" sensor return non zero value.

Can you edit the bellow file and add console.log(status, value) before that line ? https://github.com/orblazer/plasma-applet-resources-monitor/blob/21d4a25673c8e3c72433e2d942b710b1b1de1b94/package/contents/ui/components/sensors/CpuTemperature.qml#L40

[BanditSan]

After enabling temp console output

qt.svg.draw: The requested filter buffer is too big, ignoring
qml: 0 undefined
qml: 2 0
qml: 2 0
qml: 2 0
qml: 2 0
qml: 2 0
qml: 2 0
qml: 2 0
qml: 2 0
qml: 2 0
qml: 2 0
qml: 2 0

[orblazer]

OH oki i doesn't know if the sensor pass in ready status, so i will fix it in few hours.

[orblazer]

You can try with new version ;)

[BanditSan]

Now seem to be working fine.