[SOLVED] How to make cpufreqd (or acpi) read temperatures on a dual core?

the dsc · 10-21-2011, 11:13 PM

It seems that cpufreqd is trying to get the cpu/cores temperature from acpi, which is installed and working at least for making a clean shutdown when pressing the power button once, but the cpu temperature isn't available for some reason. I get cpu temperature via ksysguard (perhaps just "[kde] system guard" these days) though. It does not get its readings from acpi, it seems, as acpinfo gives "Thermal info : <not available>".

The output of "sensors -u" gives something that seems what ksysguard gets its readings from, "coretemp isa":

Code:

coretemp-isa-0000
  temp2_input: 41.000
  temp2_max: 76.000
  temp2_crit: 100.000
  temp2_crit_alarm: 0.000
  temp3_input: 41.000
  temp3_max: 76.000
  temp3_crit: 100.000
  temp3_crit_alarm: 0.000

The pertinent part on cpufreqd.conf was like this on the original configuration file:

Code:

# CPU Too hot!
[Rule]
name=CPU Too Hot
acpi_temperature=7-100

I've found at this article a different version that looked very promising:

Code:

# CPU Too hot!
[Rule]
name=CPU Too Hot
sensor=coretemp:70-100

But it didn't work. I've also tried:

Code:

# CPU Too hot!
[Rule]
name=CPU Too Hot
sensor=temp2_input:70-100

And "coretemp-isa-0000", "coretemp-isa", but neither did work.

Instead cpufreqd keeps showing:

Code:

acpi_temperature_update  : called
acpi_temperature_update  : temperature for thermal_zone0 is 30.0C
acpi_temperature_update  : temperature average is 30.0C

And this seems to be some phoney reading that keeps stationary at 30C.
I also have the following section on the same config file:

Code:

[sensors_plugin]
sensors_conf=/etc/sensors3.conf
[/sensors_plugin]

Which seems to be correct from what I've been finding, which is not much though. And this file exists.

So, anyone knows the correct syntax to use in cpufreqd.conf for this situation, or how to make acpi_temperature work for real instead?

Thanks a lot!

update: I've tried the same variations on the stock kernel, just in case. Didn't work.

update 2: tried editing sensors3.conf, it turns out that my chip had only a single line on it, not evidently related with temperatures, so I just copied some lines from other chips. Didn't work, neither did using the original obscure item/label on cpufreqd.conf.

Code:

chip "it87-*" "it8712-*" "it8716-*" "it8718-*" "it8720-*"

    label in8 "Vbat"
    label temp1 "CPU0 Temp"
    label temp2 "CPU1 Temp"

The original single line is underlined, the other two are the ones I've added.

gradinaruvasile · 10-23-2011, 02:14 PM

The temperature readings are not standardized at all. They really depend on the chiset and driver of the chipset.
Some chipsets supply information via acpi, some not.

And, some supply outright "wrong" information. For example i have an AMD Athlon II x2 250 CPU and i have 2 different readings from 2 sources - the acpi-supplied (atk0110-acpi-0) info shows the (probably) real temps (same as in BIOS at least), but the (supposedly) native Athlon II/Phenom II "k10temp" driver shows something entirely different, with ~15 degrees lower (sometimes lower than the ambient temp) - but the author himself said that these readings are used internally by the CPU/BIOS to determine the needed cooling and it is not always a real temperature.

To see what drivers are available for your chipset, run "sensors-detect" as root (or with sudo).

the dsc · 10-23-2011, 06:43 PM

It does not surprise me that temperature readings are not standardized, what I think it's a bit odd/frustrating is the difficulty to use a given available reading in some application that is using the wrong one for some reason. The reading is there but you can't use it, set on the configuration file of the application some other thing. Or maybe you can (it seems that you can), but it's rather obscure how you should do it. I think it's partly due to the coexistence of newer and modern systems, like /proc/acpi, hwmon, and /sys/class.

Anyway, I've run "sensors-detect", many times indeed. But I've run it once again just out of not having any other better choice, and I've noticed something I think I've missed before. "Coretemp" and these "it87" are two different things. I thought the "coretemp" was just a label, not a driver, but it's a driver really. But there's no "coretemp" section on "sensors3.conf". Gonna look more into it, thanks.

the dsc · 10-23-2011, 07:28 PM

I got it working!

I've made a new config file for these sensors, more or less as shown in this thread on arch linux' forums, just adapting to a mere dual core, whereas the one in the thread seems to be a bazillion cores or something.

Code:

chip "coretemp-isa-0000"

    label temp2 "Core 0"
    label temp3 "Core 1"

Then with the correspondent change in cpufreqd.conf it was reading the correct temperature, albeit it won't let go of that bogus acpitz-virtual thing. But as long as it's not taken into consideration in any cpufreqd rule, it does not matter.

The cpufreqd.conf syntax is:

sensor=sensorlabel:##-###

in actual terms:

sensor=temp2:55-70

and my "sensor plugin" points directly to /etc/sensors.d/cores.conf, just in case.

There's still something a bit weird in the fact that it seems that these labels cannot be totally arbitrary. I tried core0 and core1 for "Core 0" and "Core 1" respectively, and I've also made the required changes on cpufreqd, but then the "sensors_get" part of the output wouldn't appear. I think they may need to be labelled "temp#". Weird.

And I thought I needed to compile the kernel. I still want to do it someday, but it would probably have no effect whatsoever.