[gentoo-user] lm_sensors much hotter in 2.6.31 than 2.6.28

[gentoo-user] lm_sensors much hotter in 2.6.31 than 2.6.28

[Grant]

After upgrading from 2.6.28 to 2.6.31, I noticed my CPU temperatures
are reported a full 20C hotter.  If I load the old kernel, the
reported temperatures drops back down to normal.  Has anyone else seen
this?

- Grant

Re: [gentoo-user] lm_sensors much hotter in 2.6.31 than 2.6.28

[Volker Armin Hemmann]

On Sonntag 25 Oktober 2009, Grant wrote:
> After upgrading from 2.6.28 to 2.6.31, I noticed my CPU temperatures
> are reported a full 20C hotter.  If I load the old kernel, the
> reported temperatures drops back down to normal.  Has anyone else seen
> this?
> 
> - Grant
> 

no, but I suspect that lm_sensors is just reporting more correctly with the 
newer kernel.

Re: [gentoo-user] lm_sensors much hotter in 2.6.31 than 2.6.28

[Grant]

>> After upgrading from 2.6.28 to 2.6.31, I noticed my CPU temperatures
>> are reported a full 20C hotter.  If I load the old kernel, the
>> reported temperatures drops back down to normal.  Has anyone else seen
>> this?
>>
>> - Grant
>>
>
> no, but I suspect that lm_sensors is just reporting more correctly with the
> newer kernel.

I considered that, but the reported temps don't seem to rise and fall
with CPU activity like they did before.  I think there's a bug of some
sort here.

- Grant

Re: [gentoo-user] lm_sensors much hotter in 2.6.31 than 2.6.28

[Paul Hartman]

On Sun, Oct 25, 2009 at 4:37 PM, Grant <emailgrant@gmail.com> wrote:
> After upgrading from 2.6.28 to 2.6.31, I noticed my CPU temperatures
> are reported a full 20C hotter.  If I load the old kernel, the
> reported temperatures drops back down to normal.  Has anyone else seen
> this?

If you are using the "coretemp" sensor module, the logic by which it
reports "temperature" changed somewhere in the last few kernels. Also,
in many (most?) cases it doesn't report an actual temperature at all
but a relative one on a scale from 0-100 based on some operating range
defined by Intel? or somebody...

[gentoo-user] Re: lm_sensors much hotter in 2.6.31 than 2.6.28

[Nikos Chantziaras]

On 10/25/2009 11:37 PM, Grant wrote:
> After upgrading from 2.6.28 to 2.6.31, I noticed my CPU temperatures
> are reported a full 20C hotter.  If I load the old kernel, the
> reported temperatures drops back down to normal.  Has anyone else seen
> this?

If you're using coretemp as sensor, the temps are always off (the 
coretemp sensor of Intel chips is not accurate, not by any stretch of 
the imagination.)  It only reports the distance to the CPU's maximum 
thermal junction, which then the coretemp driver *tries* to translate 
into a temperature, but the result is wrong since the value reported by 
the CPU is not accurate to start with (it only gets accurate as you 
approach the max value).  That maximum value is totally undocumented for 
desktop CPUs (the docs Intel provided recently are wrong.)

You should use your mainboard's sensors instead for accurate values.

Re: [gentoo-user] Re: lm_sensors much hotter in 2.6.31 than 2.6.28

[Grant]

>> After upgrading from 2.6.28 to 2.6.31, I noticed my CPU temperatures
>> are reported a full 20C hotter.  If I load the old kernel, the
>> reported temperatures drops back down to normal.  Has anyone else seen
>> this?
>
> If you're using coretemp as sensor, the temps are always off (the coretemp
> sensor of Intel chips is not accurate, not by any stretch of the
> imagination.)  It only reports the distance to the CPU's maximum thermal
> junction, which then the coretemp driver *tries* to translate into a
> temperature, but the result is wrong since the value reported by the CPU is
> not accurate to start with (it only gets accurate as you approach the max
> value).  That maximum value is totally undocumented for desktop CPUs (the
> docs Intel provided recently are wrong.)
>
> You should use your mainboard's sensors instead for accurate values.

I'm actually using k8temp.  Do you think it is susceptible to the same
problems you're talking about?  I also have an ACPI sensor available
named THRM.  Should that one be more accurate?

BTW, another system of mine (Dell laptop) only seems to have available
coretemp or an ACPI sensor which reports values like 46960 mWh.  Am I
totally out of luck with that one?

So, In the end, it's fairly impossible to monitor a CPU's actual
temperature in order to keep it below the published maximum?

- Grant

Re: [gentoo-user] Re: lm_sensors much hotter in 2.6.31 than 2.6.28

[Volker Armin Hemmann]

On Montag 26 Oktober 2009, Grant wrote:
> >> After upgrading from 2.6.28 to 2.6.31, I noticed my CPU temperatures
> >> are reported a full 20C hotter.  If I load the old kernel, the
> >> reported temperatures drops back down to normal.  Has anyone else seen
> >> this?
> >
> > If you're using coretemp as sensor, the temps are always off (the
> > coretemp sensor of Intel chips is not accurate, not by any stretch of the
> > imagination.)  It only reports the distance to the CPU's maximum thermal
> > junction, which then the coretemp driver *tries* to translate into a
> > temperature, but the result is wrong since the value reported by the CPU
> > is not accurate to start with (it only gets accurate as you approach the
> > max value).  That maximum value is totally undocumented for desktop CPUs
> > (the docs Intel provided recently are wrong.)
> >
> > You should use your mainboard's sensors instead for accurate values.
> 
> I'm actually using k8temp.  Do you think it is susceptible to the same
> problems you're talking about?  I also have an ACPI sensor available
> named THRM.  Should that one be more accurate?
> 
> BTW, another system of mine (Dell laptop) only seems to have available
> coretemp or an ACPI sensor which reports values like 46960 mWh.  Am I
> totally out of luck with that one?
> 
> So, In the end, it's fairly impossible to monitor a CPU's actual
> temperature in order to keep it below the published maximum?
> 
> - Grant
> 

there are no published maximums. Ruin a good evening going through CPU specs. 

And k8temp has the same problem. Or similar. Some CPUs report correct temps, 
other doesn't and some report some complete bogonium.

Re: [gentoo-user] Re: lm_sensors much hotter in 2.6.31 than 2.6.28

[Paul Hartman]

On Mon, Oct 26, 2009 at 2:44 PM, Grant <emailgrant@gmail.com> wrote:
>>> After upgrading from 2.6.28 to 2.6.31, I noticed my CPU temperatures
>>> are reported a full 20C hotter.  If I load the old kernel, the
>>> reported temperatures drops back down to normal.  Has anyone else seen
>>> this?
>>
>> If you're using coretemp as sensor, the temps are always off (the coretemp
>> sensor of Intel chips is not accurate, not by any stretch of the
>> imagination.)  It only reports the distance to the CPU's maximum thermal
>> junction, which then the coretemp driver *tries* to translate into a
>> temperature, but the result is wrong since the value reported by the CPU is
>> not accurate to start with (it only gets accurate as you approach the max
>> value).  That maximum value is totally undocumented for desktop CPUs (the
>> docs Intel provided recently are wrong.)
>>
>> You should use your mainboard's sensors instead for accurate values.
>
> I'm actually using k8temp.  Do you think it is susceptible to the same
> problems you're talking about?  I also have an ACPI sensor available
> named THRM.  Should that one be more accurate?
>
> BTW, another system of mine (Dell laptop) only seems to have available
> coretemp or an ACPI sensor which reports values like 46960 mWh.  Am I
> totally out of luck with that one?
>
> So, In the end, it's fairly impossible to monitor a CPU's actual
> temperature in order to keep it below the published maximum?

Hmm, the k8temp documentation seems to indicate that it should be
actual temperature:

"Temperatures are measured in degrees Celsius and measurement
resolution is 1 degree C. It is expected that future CPU will have
better resolution. The temperature is updated once a second. Valid
temperatures are from -49 to 206 degrees C."

Also, with lm_sensors not all sensors can be auto-detected. I had to
manually specify mine (Abit uGuru3).