Cc: Kasper Sandberg <lkml@...>, Maxim Levitsky <maximlevitsky@...>, Len Brown <lenb@...>, Matthew <jackdachef@...>, <linux-acpi@...>, <torvalds@...>, <linux-kernel@...>, Zhang, Rui <rui.zhang@...>, Rudolf Marek <r.marek@...>
Hi all,
Adding Rudolf Marek to the thread, as he wrote the coretemp driver and
is maintaining it. He was really the first person to contact about your
problem...
On Tue, 29 Apr 2008 15:07:03 +0200, Thomas Renninger wrote:
And how do you know? The newly reported temperatures could be correct
and the previous ones were incorrect (that's actually the case.) The
thing is, the temperature is stored as a relative value in the CPU.
Relative to what, depends on the CPU model, can be 85°C or 100°C. Up to
kernel 2.6.24 we had a set of rules to find out, in 2.6.25 we have a
presumably better heuristic. So some people have seen their CPU
temperature climb by 15°C and others drop by 15°C, that's expected.
The coretemp driver reports the CPU _core_ temperature. That's not
something you can touch, believe me (unless you are an electron.)
Also note that the CPU temperature reported by the IT8718F may or may
not match the reality. To make sure, you'd need to know the type of
thermal diode expected by the IT8718F, the type of thermal diode in
your CPU, compute the correction factor if there is one. And you'd need
to know where the thermal diode is exactly. It is most certainly built
into the CPU, but some motherboard makers are doing weird things.
22°C seems very low to me, even for water-cooling. Note that
non-linearity of thermal diodes makes measurements inaccurate as they
get away from the expected operating point. I guess that thermal diodes
used in CPUs are calibrated for best results around the expected
temperature when using air-cooling, rather than water-cooling.
I still need to be convinced that there is a bug here.
In my experience, the BIOS is more likely to get the information from
the on-board hardware monitoring chip than from the CPU MSRs as the
coretemp driver does.
If that windows tool was not written by Intel, then chances are that
the author had as much difficulties as we did to get the correct TJmax
values for the different CPU models, so it's hardly meaningful. And
even a tool written by Intel themselves, I wouldn't necessarily trust
it, given how hard it was to get the information from them.
Which driver, which kernel? As I wrote above, the coretemp heuristic
changed in kernel 2.6.25, so the fact that a previous kernel was
reporting a different tjmax value is irrelevant. Unless you have
additional documentation from Intel, I would tend to believe that the
coretemp driver in 2.6.25 is correct. But feel free to report the exact
CPU model you have (with CPUID info) to Rudolf, if he gets enough
reports about a specific CPU model which most people believe gets the
wrong tjmax, he can fix the driver.
That's a possibility for sure, but what we would really need is to
adjust the coretemp driver heuristics to always get it right - if
that's not already the case, that is. I'll let Rudolf decide anyway.
Note that all in all, the absolute temperature doesn't really matter
anyway. What matters is how far you are from TJmax.
No, there's a much more simple explanation for this change users are
reporting, see above. Plus, I fail to see how ACPI could interfere with
the coretemp driver as all, as it gets its values from MSRs and not I/O
ports.
--
Jean Delvare
--
