Linux 2.6.25

Linux 2.6.25

[Matthew]

Hi everyone, hi Linus,

congratulations on this new great kernel-release :)

I've another "regression" to report for 2.6.25:

it's concerning much higher temperatures being read out by the
"coretemp" kernel-module in comparison to 2.6.24* series

e.g. where temperatures were around 40-47°C they are now constantly
jumping around 55-70°C (even in idle !)

several other users/testers have reported this issue too (both on
zen-sources [heavy patched] & latest gentoo-sources) [slightly
patched]:

http://forums.gentoo.org/viewtopic-t-684812-highlight-.html

if I understood git right it (also) happens in conjunction with an 3
weeks old acpi-snapshot
(http://repo.or.cz/w/linux-2.6/zen-sources.git?a=heads) integrated in
zen-sources

I can "reproduce" this on an Intel Core 2 Duo 6600 (Conroe) with a P5W
DH Deluxe mainboard (by Asus) since at least 2.6.25-rc8 (or possibly
also rc7)

the temperatures on mobile core (2) duo intel processors [e.g. an
T7500] seem to be read out correctly - I can't tell it exactly but
this seems to be an entirely "cosmetical" issue
(hopefully it's not the opposite and the values are now read out
correctly since such high temps would be very worrying ;) )

Keep up the great work & please don't forget your growing amount of
linux-desktop users :)

Regards

Mat

Re: Linux 2.6.25

[Linus Torvalds]

On Fri, 18 Apr 2008, Matthew wrote:
> 
> I can "reproduce" this on an Intel Core 2 Duo 6600 (Conroe) with a P5W
> DH Deluxe mainboard (by Asus) since at least 2.6.25-rc8 (or possibly
> also rc7)

Can you bisect it? 

		Linus

Re: Linux 2.6.25

[Matthew]

On Fri, Apr 18, 2008 at 5:43 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
>  On Fri, 18 Apr 2008, Matthew wrote:
>  >
>  > I can "reproduce" this on an Intel Core 2 Duo 6600 (Conroe) with a P5W
>  > DH Deluxe mainboard (by Asus) since at least 2.6.25-rc8 (or possibly
>  > also rc7)
>
>  Can you bisect it?
>
>                 Linus
>

sorry, unfortunately I don't have the time right now to do it (exams-time),

I hope that someone out of the gentoo-community would be willing to do
so, I'll post a link to this entry in the forums & hope that someone
can be found to do it

Regards

Mat

Re: Linux 2.6.25

[Cyrill Gorcunov]

[Linus Torvalds - Fri, Apr 18, 2008 at 08:43:35AM -0700]
| 
| 
| On Fri, 18 Apr 2008, Matthew wrote:
| > 
| > I can "reproduce" this on an Intel Core 2 Duo 6600 (Conroe) with a P5W
| > DH Deluxe mainboard (by Asus) since at least 2.6.25-rc8 (or possibly
| > also rc7)
| 
| Can you bisect it? 
| 
| 		Linus

it seems drivers/acpi/thermal.c has a small nit

881:	/* sys I/F for generic thermal sysfs support */
882:	#define KELVIN_TO_MILLICELSIUS(t) (t * 100 - 273200)

but it should multiply by 1000 meguess

		- Cyrill -

Re: Linux 2.6.25

[Cyrill Gorcunov]

[Cyrill Gorcunov - Fri, Apr 18, 2008 at 11:38:02PM +0400]
| [Linus Torvalds - Fri, Apr 18, 2008 at 08:43:35AM -0700]
| | 
| | 
| | On Fri, 18 Apr 2008, Matthew wrote:
| | > 
| | > I can "reproduce" this on an Intel Core 2 Duo 6600 (Conroe) with a P5W
| | > DH Deluxe mainboard (by Asus) since at least 2.6.25-rc8 (or possibly
| | > also rc7)
| | 
| | Can you bisect it? 
| | 
| | 		Linus
| 
| it seems drivers/acpi/thermal.c has a small nit
| 
| 881:	/* sys I/F for generic thermal sysfs support */
| 882:	#define KELVIN_TO_MILLICELSIUS(t) (t * 100 - 273200)
| 
| but it should multiply by 1000 meguess
| 

oh, i'm wrong, sorry

		- Cyrill -

Re: Linux 2.6.25

[Rene Herman]

On 18-04-08 22:03, Cyrill Gorcunov wrote:

> | it seems drivers/acpi/thermal.c has a small nit
> | 
> | 881:	/* sys I/F for generic thermal sysfs support */
> | 882:	#define KELVIN_TO_MILLICELSIUS(t) (t * 100 - 273200)
> | 
> | but it should multiply by 1000 meguess
> | 
> 
> oh, i'm wrong, sorry

? How are you wrong ?

Rene.

Re: Linux 2.6.25

[Rene Herman]

On 19-04-08 05:05, Rene Herman wrote:
> On 18-04-08 22:03, Cyrill Gorcunov wrote:
> 
>> | it seems drivers/acpi/thermal.c has a small nit
>> | | 881:    /* sys I/F for generic thermal sysfs support */
>> | 882:    #define KELVIN_TO_MILLICELSIUS(t) (t * 100 - 273200)
>> | | but it should multiply by 1000 meguess
>> |
>> oh, i'm wrong, sorry
> 
> ? How are you wrong ?

(okay, it's only the name which is wrong; it's DECIKELVIN_TO_MILLICELSIUS)

Rene.

Re: Linux 2.6.25

[Cyrill Gorcunov]

[Rene Herman - Sat, Apr 19, 2008 at 05:20:23AM +0200]
> On 19-04-08 05:05, Rene Herman wrote:
>> On 18-04-08 22:03, Cyrill Gorcunov wrote:
>>> | it seems drivers/acpi/thermal.c has a small nit
>>> | | 881:    /* sys I/F for generic thermal sysfs support */
>>> | 882:    #define KELVIN_TO_MILLICELSIUS(t) (t * 100 - 273200)
>>> | | but it should multiply by 1000 meguess
>>> |
>>> oh, i'm wrong, sorry
>> ? How are you wrong ?
>
> (okay, it's only the name which is wrong; it's DECIKELVIN_TO_MILLICELSIUS)
>
> Rene.
>

yep, I was confused by these names too ;)

		- Cyrill -

Re: Linux 2.6.25

[Matthew]

>Hello Mat,
>I'm not familiar with "coretemp", can you point me to the exact version
>of the application you are running so I can see how it is getting at
>the underlying information?

>Also, do you see any change with and without kernel built with
CONFIG_THERMAL=y?

>thanks,
>-Len

Hi Len,

sure, the apps I am using for reading out the processor's temp via
coretemp are / were:
lm_sensors: version 2.10.4, 2.10.6 and (currently) 3.0.1: all report
the same (higher) temperatures (compared to 2.6.24 series)

CONFIG_THERMAL currently is enabled in the kernel:
grep CONFIG_THERMAL /usr/src/linux/.config
CONFIG_THERMAL=y

I'll recompile the kernel now & let you know the effect in a few hours
(currently I'm working on the box)

"Dairinin" on forums.gentoo.org pointed out that the desktop-cpu
simply might not be identified correctly:
http://forums.gentoo.org/viewtopic-p-5065902.html#5065902

"Thats because new kernel (lm_sensors, etc?, etc?)incorrectly thinks
our cpu's Tj is 100C, whereas for all core 2 duo's it is 85C (100C is
for C0 stepping and above, AFAIK). Substract 15 and you'll get real
temps."

I don't know if that's the case but it sounds plausible to me

thanks everyone for your answer & help so far

Regards

Mat

Re: Linux 2.6.25

[Matthew]

>The coretemp kernel module reports 25°C on my PC when idle, and 34°C
>after having performed some computations (lmbench2). This looks
>normal. This test has been performed with a vanilla 2.6.25 kernel and
>a Core 2 Duo E6750 CPU (Asus motherboard). The 2.6.22 and 2.6.24
>kernels report an incorrect temperature on the same system however
>(10°C). So there is either an issue with the patches that have been
>applied to your kernel or the behavior of the coretemp module for the
>6600 and E6750 CPU's is different. Can you repeat the test with a
>vanilla 2.6.25 kernel ?

>(Added Rudolf Marek in CC, the coretemp author.)

>Bart.

sure, I'll test-drive the vanilla-kernel, too

thanks

Mat

Re: Linux 2.6.25

[Matthew]

>  sure, I'll test-drive the vanilla-kernel, too>>  thanks
ok, tested the vanilla-kernel this morning and it shows the exact hightemperatures (with CONFIG_THERMAL=y)
I've got a question:
when trying to disable thermal it just sits there & won't change:<*> Hardware Monitoring support  --->  -*- Generic Thermal sysfs driver  --->
it seemingly depends on other things:Selected by: ACPI_THERMAL && !X86_VOYAGER && ACPI && ACPI_PROCESSOR
is it safe to disable acpi_processor and acpi or CONFIG_THERMAL ingeneral ? or will it burn down my box ? ;)
I'm asking this because it says/writes:CONFIG_ACPI_THERMAL:                                                    │  │                                                                         │  │ This driver adds support for ACPI thermal zones.  Most mobile and       │  │ some desktop systems support ACPI thermal zones.  It is HIGHLY          │  │ recommended that this option be enabled, as your processor(s)           │  │ may be damaged without it.

thanks
MatЪТХ╨{.nг+┴╥÷╝┴╜├+%┼кЪ╠Ищ╤\x17╔┼wЪ╨{.nг+┴╥╔┼{╠ЧG╚²ИЪ┼{ay╨\x1dй┤з≥К,j\a╜╒fё╒╥h ▐О│ЙЪ▒ЙГz_Х╝\x03(╜И ▌┼щ╒j"²З\x1a╤^[m╖ЪЪ╬\a╚ЧG╚²ИЪ╒╦?≥╗Х╜з&ёЬ╖~▐А╤iO∙Ф╛z╥ vь^\x14\x04\x1a╤^[m╖ЪЪц\fЪ╤ЛЪ╒╦?√I╔

Re: Linux 2.6.25

[Len Brown]

On Sunday 20 April 2008, Matthew wrote:
> >  sure, I'll test-drive the vanilla-kernel, too
> >
> >  thanks
> 
> ok, tested the vanilla-kernel this morning and it shows the exact high
> temperatures (with CONFIG_THERMAL=y)
> 
> I've got a question:
> 
> when trying to disable thermal it just sits there & won't change:
> <*> Hardware Monitoring support  --->
>   -*- Generic Thermal sysfs driver  --->
> 
> it seemingly depends on other things:
> Selected by: ACPI_THERMAL && !X86_VOYAGER && ACPI && ACPI_PROCESSOR
> 
> is it safe to disable acpi_processor and acpi or CONFIG_THERMAL in
> general ? or will it burn down my box ? ;)
> 
> I'm asking this because it says/writes:
> CONFIG_ACPI_THERMAL:                                                    │
>   │                                                                         │
>   │ This driver adds support for ACPI thermal zones.  Most mobile and       │
>   │ some desktop systems support ACPI thermal zones.  It is HIGHLY          │
>   │ recommended that this option be enabled, as your processor(s)           │
>   │ may be damaged without it.

Don't worry about it -- that is sort of an exageration.
In fact, it is your disk drive that will fry first:-)

# CONFIG_ACPI_THERMAL is not set
# CONFIG_THERMAL is not set

Should be just fine, particularly for experimentation.
In the case of a desktop system, ACPI_THERMAL is generally there
just for processor throttling -- which would typically
only be needed if you removed your heatsink
or had some other serious cooling issue.
And even if it is not there, a 2nd defense,
the processor hardware thermal throttling would kick
in automatically at a slightly higher temperature...

-Len

Re: Linux 2.6.25

[Gene Heskett]

On Friday 18 April 2008, Matthew wrote:
>Hi everyone, hi Linus,
>
>congratulations on this new great kernel-release :)
>
>I've another "regression" to report for 2.6.25:
>
>it's concerning much higher temperatures being read out by the
>"coretemp" kernel-module in comparison to 2.6.24* series
>
>e.g. where temperatures were around 40-47°C they are now constantly
>jumping around 55-70°C (even in idle !)
>
>several other users/testers have reported this issue too (both on
>zen-sources [heavy patched] & latest gentoo-sources) [slightly
>patched]:
>
>http://forums.gentoo.org/viewtopic-t-684812-highlight-.html
>
>if I understood git right it (also) happens in conjunction with an 3
>weeks old acpi-snapshot
>(http://repo.or.cz/w/linux-2.6/zen-sources.git?a=heads) integrated in
>zen-sources
>
>I can "reproduce" this on an Intel Core 2 Duo 6600 (Conroe) with a P5W
>DH Deluxe mainboard (by Asus) since at least 2.6.25-rc8 (or possibly
>also rc7)
>
>the temperatures on mobile core (2) duo intel processors [e.g. an
>T7500] seem to be read out correctly - I can't tell it exactly but
>this seems to be an entirely "cosmetical" issue
>(hopefully it's not the opposite and the values are now read out
>correctly since such high temps would be very worrying ;) )
>
>Keep up the great work & please don't forget your growing amount of
>linux-desktop users :)
>
Amen on that.  And to add confusion here, my makeit script started dying when 
I do a remake after changing a config option, cuz it can't find a System.map 
file to delete, even if I copy it in from /boot.  I had to delete the make 
clean line of the script. Odd.

>Regards
>
>Mat
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Check it out, send me comments, and dance joyously in the streets,
	-- Linus Torvalds announcing 2.0.27

Re: Linux 2.6.25

[Gene Heskett]

On Friday 18 April 2008, Matthew wrote:
>Hi everyone, hi Linus,
>
>congratulations on this new great kernel-release :)
>
>I've another "regression" to report for 2.6.25:
>
>it's concerning much higher temperatures being read out by the
>"coretemp" kernel-module in comparison to 2.6.24* series
>
>e.g. where temperatures were around 40-47°C they are now constantly
>jumping around 55-70°C (even in idle !)
>
>several other users/testers have reported this issue too (both on
>zen-sources [heavy patched] & latest gentoo-sources) [slightly
>patched]:
>
>http://forums.gentoo.org/viewtopic-t-684812-highlight-.html
>
>if I understood git right it (also) happens in conjunction with an 3
>weeks old acpi-snapshot
>(http://repo.or.cz/w/linux-2.6/zen-sources.git?a=heads) integrated in
>zen-sources
>
>I can "reproduce" this on an Intel Core 2 Duo 6600 (Conroe) with a P5W
>DH Deluxe mainboard (by Asus) since at least 2.6.25-rc8 (or possibly
>also rc7)
>
>the temperatures on mobile core (2) duo intel processors [e.g. an
>T7500] seem to be read out correctly - I can't tell it exactly but
>this seems to be an entirely "cosmetical" issue
>(hopefully it's not the opposite and the values are now read out
>correctly since such high temps would be very worrying ;) )
>
>Keep up the great work & please don't forget your growing amount of
>linux-desktop users :)
>
And then, after killing the make clean statement, it still dies when making a 
new initrd-2.6.25.img.  Has something in the Makefile gone doofy?

>Regards
>
>Mat
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Check it out, send me comments, and dance joyously in the streets,
	-- Linus Torvalds announcing 2.0.27

Re: Linux 2.6.25

[Bart Van Assche]

On Fri, Apr 18, 2008 at 5:37 PM, Matthew <jackdachef@gmail.com> wrote:
>  I've another "regression" to report for 2.6.25:
>
>  it's concerning much higher temperatures being read out by the
>  "coretemp" kernel-module in comparison to 2.6.24* series
>
>  e.g. where temperatures were around 40-47°C they are now constantly
>  jumping around 55-70°C (even in idle !)

The coretemp kernel module reports 25°C on my PC when idle, and 34°C
after having performed some computations (lmbench2). This looks
normal. This test has been performed with a vanilla 2.6.25 kernel and
a Core 2 Duo E6750 CPU (Asus motherboard). The 2.6.22 and 2.6.24
kernels report an incorrect temperature on the same system however
(10°C). So there is either an issue with the patches that have been
applied to your kernel or the behavior of the coretemp module for the
6600 and E6750 CPU's is different. Can you repeat the test with a
vanilla 2.6.25 kernel ?

(Added Rudolf Marek in CC, the coretemp author.)

Bart.

Re: Linux 2.6.25

[Jiri Slaby]

On 04/18/2008 09:18 PM, Bart Van Assche wrote:
> On Fri, Apr 18, 2008 at 5:37 PM, Matthew <jackdachef@gmail.com> wrote:
>>  I've another "regression" to report for 2.6.25:
>>
>>  it's concerning much higher temperatures being read out by the
>>  "coretemp" kernel-module in comparison to 2.6.24* series
>>
>>  e.g. where temperatures were around 40-47°C they are now constantly
>>  jumping around 55-70°C (even in idle !)
> 
> The coretemp kernel module reports 25°C on my PC when idle, and 34°C
> after having performed some computations (lmbench2). This looks
> normal. This test has been performed with a vanilla 2.6.25 kernel and
> a Core 2 Duo E6750 CPU (Asus motherboard). The 2.6.22 and 2.6.24
> kernels report an incorrect temperature on the same system however
> (10°C). So there is either an issue with the patches that have been
> applied to your kernel or the behavior of the coretemp module for the
> 6600 and E6750 CPU's is different. Can you repeat the test with a
> vanilla 2.6.25 kernel ?
> 
> (Added Rudolf Marek in CC, the coretemp author.)

I see a change on my rrd graphs on Mar 5th 11:30 AM (from 25 to 40 average 
centigrades). This is when I booted 2.6.25-rc3-mm1 instead of 2.6.25-rc2-mm1, 
according to logs. [I have no idea whether the values were correct before or are 
correct now.]

I might bisect it, if needed.

Re: Linux 2.6.25

[Rudolf Marek]

Hi all,

I will keep the rest of the mail intact for the lm-sensors list. The temperature 
is stored in hardware relative to maximum temperature. Mobile processors have 
some undocumented bits that calibrate the temperature to 85 or 100C. Intel 
claims that this does not work for desktops, so I changed the driver [1] and 
scale for desktop CPUs is from 0 to 100.

In your case, the MAX temperature is changed from 85 to 100 for desktops But the 
relative change is same, in your case -40C below the max [2]. You should now see 
instead of 40 around 60. Because it was 85 - 40 and now it is 100 - 40. Second 
problem is that the scale is not linear so it works more fine close to the MAX.

I think it is what happened. If you change the driver, so it will take 85C 
instead of 100C everything should go back to "normal". I'm sorry I did not 
invent relative only temp measurements, therefore I would recommend to watch how 
much is left to max temperature.

Hope it explains it,

Thanks,
Rudolf

[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=118a88718886a6cb7fb2cf7fb77ef2eea30c73a1
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/hwmon/coretemp;hb=HEAD


Jiri Slaby napsal(a):
> On 04/18/2008 09:18 PM, Bart Van Assche wrote:
>> On Fri, Apr 18, 2008 at 5:37 PM, Matthew <jackdachef@gmail.com> wrote:
>>>  I've another "regression" to report for 2.6.25:
>>>
>>>  it's concerning much higher temperatures being read out by the
>>>  "coretemp" kernel-module in comparison to 2.6.24* series
>>>
>>>  e.g. where temperatures were around 40-47°C they are now constantly
>>>  jumping around 55-70°C (even in idle !)
>>
>> The coretemp kernel module reports 25°C on my PC when idle, and 34°C
>> after having performed some computations (lmbench2). This looks
>> normal. This test has been performed with a vanilla 2.6.25 kernel and
>> a Core 2 Duo E6750 CPU (Asus motherboard). The 2.6.22 and 2.6.24
>> kernels report an incorrect temperature on the same system however
>> (10°C). So there is either an issue with the patches that have been
>> applied to your kernel or the behavior of the coretemp module for the
>> 6600 and E6750 CPU's is different. Can you repeat the test with a
>> vanilla 2.6.25 kernel ?
>>
>> (Added Rudolf Marek in CC, the coretemp author.)
> 
> I see a change on my rrd graphs on Mar 5th 11:30 AM (from 25 to 40 
> average centigrades). This is when I booted 2.6.25-rc3-mm1 instead of 
> 2.6.25-rc2-mm1, according to logs. [I have no idea whether the values 
> were correct before or are correct now.]
> 
> I might bisect it, if needed.

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Len Brown]

On Friday 18 April 2008, Matthew wrote:
> Hi everyone, hi Linus,
> 
> congratulations on this new great kernel-release :)
> 
> I've another "regression" to report for 2.6.25:
> 
> it's concerning much higher temperatures being read out by the
> "coretemp" kernel-module in comparison to 2.6.24* series
> 
> e.g. where temperatures were around 40-47°C they are now constantly
> jumping around 55-70°C (even in idle !)
> 
> several other users/testers have reported this issue too (both on
> zen-sources [heavy patched] & latest gentoo-sources) [slightly
> patched]:
> 
> http://forums.gentoo.org/viewtopic-t-684812-highlight-.html
> 
> if I understood git right it (also) happens in conjunction with an 3
> weeks old acpi-snapshot
> (http://repo.or.cz/w/linux-2.6/zen-sources.git?a=heads) integrated in
> zen-sources
> 
> I can "reproduce" this on an Intel Core 2 Duo 6600 (Conroe) with a P5W
> DH Deluxe mainboard (by Asus) since at least 2.6.25-rc8 (or possibly
> also rc7)
> 
> the temperatures on mobile core (2) duo intel processors [e.g. an
> T7500] seem to be read out correctly - I can't tell it exactly but
> this seems to be an entirely "cosmetical" issue
> (hopefully it's not the opposite and the values are now read out
> correctly since such high temps would be very worrying ;) )
> 
> Keep up the great work & please don't forget your growing amount of
> linux-desktop users :)
> 
> Regards
> 
> Mat

Hello Mat,
I'm not familiar with "coretemp", can you point me to the exact version
of the application you are running so I can see how it is getting at
the underlying information?

Also, do you see any change with and without kernel built with CONFIG_THERMAL=y?

thanks,
-Len

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

Len Brown schrieb:
> Hello Mat,
> I'm not familiar with "coretemp", can you point me to the exact version
> of the application you are running so I can see how it is getting at
> the underlying information?

I think there is some confusion here: "coretemp" is a kernel module, and 
all applications reading it will probably use the lm_sensors libraries. 
(I don't think the hwmon module are related to ACPI)

$ modinfo coretemp
filename:       /lib/modules/2.6.25-ARCH/kernel/drivers/hwmon/coretemp.ko
license:        GPL
description:    Intel Core temperature monitor
author:         Rudolf Marek <r.marek@assembler.cz>
depends:
vermagic:       2.6.25-ARCH SMP preempt mod_unload

That said, I have two Core 2 CPUs (one mobile, one desktop) and the 
values coretemp reports have not changed compared to earlier kernel 
versions (around 60°C when idle on the mobile, much less on the desktop).

 > Also, do you see any change with and without kernel built with 
CONFIG_THERMAL=y?

The values I see from ACPI thermal are also the same as before (this is 
funny: they are always about 15°C cooler than the coretemp values).

So I don't see a regression here, maybe the reporter should try a 
vanilla kernel.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Matthew]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 2742 bytes --]

On Mon, Apr 21, 2008 at 6:10 PM, Thomas Bächler <thomas@archlinux.org> wrote:> Len Brown schrieb:>>> > Hello Mat,> > I'm not familiar with "coretemp", can you point me to the exact version> > of the application you are running so I can see how it is getting at> > the underlying information?> >>>  I think there is some confusion here: "coretemp" is a kernel module, and> all applications reading it will probably use the lm_sensors libraries. (I> don't think the hwmon module are related to ACPI)>>  $ modinfo coretemp>  filename:       /lib/modules/2.6.25-ARCH/kernel/drivers/hwmon/coretemp.ko>  license:        GPL>  description:    Intel Core temperature monitor>  author:         Rudolf Marek <r.marek@assembler.cz>>  depends:>  vermagic:       2.6.25-ARCH SMP preempt mod_unload>>  That said, I have two Core 2 CPUs (one mobile, one desktop) and the values> coretemp reports have not changed compared to earlier kernel versions> (around 60°C when idle on the mobile, much less on the desktop).>>>  > Also, do you see any change with and without kernel built with> CONFIG_THERMAL=y?>>  The values I see from ACPI thermal are also the same as before (this is> funny: they are always about 15°C cooler than the coretemp values).>>  So I don't see a regression here, maybe the reporter should try a vanilla> kernel.>>
thermal isn't working on this board (if you mean /proc/acpi/thermal_zone ...)
I also tried a vanilla kernel & it showed the same higher temperature ;(
here the last mail (on lkml it was corrupted) - I don't know if youwere able to read it
>  sure, I'll test-drive the vanilla-kernel, too>>  thanks
ok, tested the vanilla-kernel this morning and it shows the exact hightemperatures (with CONFIG_THERMAL=y)
I've got a question:
when trying to disable thermal it just sits there & won't change:<*> Hardware Monitoring support  ---> -*- Generic Thermal sysfs driver  --->
it seemingly depends on other things:Selected by: ACPI_THERMAL && !X86_VOYAGER && ACPI && ACPI_PROCESSOR
is it safe to disable acpi_processor and acpi or CONFIG_THERMAL ingeneral ? or will it burn down my box ? ;)
I'm asking this because it says/writes:CONFIG_ACPI_THERMAL:                                                    │ │                                                                         │ │ This driver adds support for ACPI thermal zones.  Most mobile and       │ │ some desktop systems support ACPI thermal zones.  It is HIGHLY          │ │ recommended that this option be enabled, as your processor(s)           │ │ may be damaged without it.

thanks
Matÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Fwd: Linux 2.6.25 (coretemp reads high temperatures)

[Matthew]

(this is the last mail I sent, I apologize if it got there already
correctly and only my browser displays it corrupted on lkml.org)

thermal isn't working on this board (if you mean /proc/acpi/thermal_zone ...)

I also tried a vanilla kernel & it showed the same higher temperature ;(

here the last mail (on lkml it was corrupted) - I don't know if you
were able to read it

>  sure, I'll test-drive the vanilla-kernel, too
>
>  thanks

ok, tested the vanilla-kernel this morning and it shows the exact high
temperatures (with CONFIG_THERMAL=y)

I've got a question:

when trying to disable thermal it just sits there & won't change:
<*> Hardware Monitoring support  --->
 -*- Generic Thermal sysfs driver  --->

it seemingly depends on other things:
Selected by: ACPI_THERMAL && !X86_VOYAGER && ACPI && ACPI_PROCESSOR

is it safe to disable acpi_processor and acpi or CONFIG_THERMAL in
general ? or will it burn down my box ? ;)

I'm asking this because it says/writes:
CONFIG_ACPI_THERMAL:

This driver adds support for ACPI thermal zones.  Most mobile and
some desktop systems support ACPI thermal zones.  It is HIGHLY
recommended that this option be enabled, as your processor(s)
may be damaged without it.


thanks

Mat

Fwd: Linux 2.6.25 (coretemp reads high temperatures)

[Matthew]

---------- Forwarded message ----------
...

(this is the last mail I sent, I apologize if it got there already
 correctly and only my browser displays it corrupted on lkml.org)



 thermal isn't working on this board (if you mean /proc/acpi/thermal_zone ...)

 I also tried a vanilla kernel & it showed the same higher temperature ;(

 here the last mail (on lkml it was corrupted) - I don't know if you
 were able to read it

 >  sure, I'll test-drive the vanilla-kernel, too
 >
 >  thanks

 ok, tested the vanilla-kernel this morning and it shows the exact high
 temperatures (with CONFIG_THERMAL=y)

 I've got a question:

 when trying to disable thermal it just sits there & won't change:
 <*> Hardware Monitoring support  --->
  -*- Generic Thermal sysfs driver  --->

 it seemingly depends on other things:
 Selected by: ACPI_THERMAL && !X86_VOYAGER && ACPI && ACPI_PROCESSOR

 is it safe to disable acpi_processor and acpi or CONFIG_THERMAL in
 general ? or will it burn down my box ? ;)

 I'm asking this because it says/writes:
 CONFIG_ACPI_THERMAL:

 This driver adds support for ACPI thermal zones.  Most mobile and
 some desktop systems support ACPI thermal zones.  It is HIGHLY
 recommended that this option be enabled, as your processor(s)
 may be damaged without it.


 thanks

 Mat

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Maxim Levitsky]

On Saturday, 19 April 2008 04:51:48 Len Brown wrote:
> On Friday 18 April 2008, Matthew wrote:
> > Hi everyone, hi Linus,
> > 
> > congratulations on this new great kernel-release :)
> > 
> > I've another "regression" to report for 2.6.25:
> > 
> > it's concerning much higher temperatures being read out by the
> > "coretemp" kernel-module in comparison to 2.6.24* series
> > 
> > e.g. where temperatures were around 40-47°C they are now constantly
> > jumping around 55-70°C (even in idle !)

I just updated from 2.6.24 to 2.6.25
(I usually follow whole development cycle, but I was very busy, so I skipped 2.6.25 cycle)

I confirm this.
I *know* that temperatures reported now are wrong.

The reason is that bios did report same temperatures as coretemp in 2.6.24,
moreover some time ago I have run a cpu tool (don't remember its name) on windows
which similar to coretemp reads from each core directly, sensor data , 
and I noticed that temperature that bios reports is exactly the average 
temperature of both cores
(I had to run this on windows - intel haven't released 
drivers for their QST for temperature monitoring from bios - very sad)

And the driver did say in kernel log that TJMAX is 85C

Lets at least make a kernel option to override tjmax?

Best regards,
	Maxim Levitsky

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Kasper Sandberg]

On Wed, 2008-04-23 at 11:43 +0300, Maxim Levitsky wrote:
> On Saturday, 19 April 2008 04:51:48 Len Brown wrote:
> > On Friday 18 April 2008, Matthew wrote:
> > > Hi everyone, hi Linus,
> > > 
> > > congratulations on this new great kernel-release :)
> > > 
> > > I've another "regression" to report for 2.6.25:
> > > 
> > > it's concerning much higher temperatures being read out by the
> > > "coretemp" kernel-module in comparison to 2.6.24* series
> > > 
> > > e.g. where temperatures were around 40-47°C they are now constantly
> > > jumping around 55-70°C (even in idle !)
> 
> I just updated from 2.6.24 to 2.6.25
> (I usually follow whole development cycle, but I was very busy, so I skipped 2.6.25 cycle)
> 
> I confirm this.
> I *know* that temperatures reported now are wrong.

I too can confirm that it reports incorrect temperatures.

I have a Q9450, and this is my "sensors" output:
it8718-isa-0290
Adapter: ISA adapter
<snip>
temp1:       +44°C  (low  =  +127°C, high =  +127°C)   sensor =
thermistor
temp2:       +22°C  (low  =  +127°C, high =   +60°C)   sensor = diode
temp3:        -2°C  (low  =  +127°C, high =  +127°C)   sensor =
thermistor
vid:      +0.000 V

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +44°C  (high =  +100°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +44°C  (high =  +100°C)

coretemp-isa-0002
Adapter: ISA adapter
Core 2:      +43°C  (high =  +100°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 3:      +41°C  (high =  +100°C)


temp2 is the cpu temperature(matches bios), temp1 is the northbridge(i
think, bios says "system temp").

i have watercooling, and well :P when i touch the "tube", its normal
room temperature, and believe me, i would notice if it was 45.. this is
with my cpu at idle - at full load on all 4 cores, temp2 says 35, and
~60 on coretemp, and THIS i would surely be able to notice over room
temp :)

any progress on this bug?

> 
> The reason is that bios did report same temperatures as coretemp in 2.6.24,
> moreover some time ago I have run a cpu tool (don't remember its name) on windows
> which similar to coretemp reads from each core directly, sensor data , 
> and I noticed that temperature that bios reports is exactly the average 
> temperature of both cores
> (I had to run this on windows - intel haven't released 
> drivers for their QST for temperature monitoring from bios - very sad)
> 
> And the driver did say in kernel log that TJMAX is 85C
> 
> Lets at least make a kernel option to override tjmax?
> 
> Best regards,
> 	Maxim Levitsky
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Thomas Renninger]

On Mon, 2008-04-28 at 20:19 +0200, Kasper Sandberg wrote:
> On Wed, 2008-04-23 at 11:43 +0300, Maxim Levitsky wrote:
> > On Saturday, 19 April 2008 04:51:48 Len Brown wrote:
> > > On Friday 18 April 2008, Matthew wrote:
> > > > Hi everyone, hi Linus,
> > > > 
> > > > congratulations on this new great kernel-release :)
> > > > 
> > > > I've another "regression" to report for 2.6.25:
> > > > 
> > > > it's concerning much higher temperatures being read out by the
> > > > "coretemp" kernel-module in comparison to 2.6.24* series
> > > > 
> > > > e.g. where temperatures were around 40-47°C they are now constantly
> > > > jumping around 55-70°C (even in idle !)
> > 
> > I just updated from 2.6.24 to 2.6.25
> > (I usually follow whole development cycle, but I was very busy, so I skipped 2.6.25 cycle)
> > 
> > I confirm this.
> > I *know* that temperatures reported now are wrong.
> 
> I too can confirm that it reports incorrect temperatures.
> 
> I have a Q9450, and this is my "sensors" output:
> it8718-isa-0290
> Adapter: ISA adapter
> <snip>
> temp1:       +44°C  (low  =  +127°C, high =  +127°C)   sensor =
> thermistor
> temp2:       +22°C  (low  =  +127°C, high =   +60°C)   sensor = diode
> temp3:        -2°C  (low  =  +127°C, high =  +127°C)   sensor =
> thermistor
> vid:      +0.000 V
> 
> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0:      +44°C  (high =  +100°C)
> 
> coretemp-isa-0001
> Adapter: ISA adapter
> Core 1:      +44°C  (high =  +100°C)
> 
> coretemp-isa-0002
> Adapter: ISA adapter
> Core 2:      +43°C  (high =  +100°C)
> 
> coretemp-isa-0003
> Adapter: ISA adapter
> Core 3:      +41°C  (high =  +100°C)
> 
> 
> temp2 is the cpu temperature(matches bios), temp1 is the northbridge(i
> think, bios says "system temp").
> 
> i have watercooling, and well :P when i touch the "tube", its normal
> room temperature, and believe me, i would notice if it was 45.. this is
> with my cpu at idle - at full load on all 4 cores, temp2 says 35, and
> ~60 on coretemp, and THIS i would surely be able to notice over room
> temp :)
> 
> any progress on this bug?
> 
> > 
> > The reason is that bios did report same temperatures as coretemp in 2.6.24,
> > moreover some time ago I have run a cpu tool (don't remember its name) on windows
> > which similar to coretemp reads from each core directly, sensor data , 
> > and I noticed that temperature that bios reports is exactly the average 
> > temperature of both cores
> > (I had to run this on windows - intel haven't released 
> > drivers for their QST for temperature monitoring from bios - very sad)
> > 
> > And the driver did say in kernel log that TJMAX is 85C
> > 
> > Lets at least make a kernel option to override tjmax?
> > 

Could it be that due to latest thermal changes ACPI is reading
temperatures more often, or started to read sensors that interfere with
libsensors?

There was a patch-set that detect such interference from myself and Jean
which was not accepted by Linus.
This is what I got from Jean recently, he should be able to point you to
the latest patches if you want to give them a try:
----------------------------------------------
On Mon, 28 Apr 2008 22:13:13 -0700, Andrew Morton wrote:
> In light of Linus's dummyspit last time around I guess I'll drop
> this patch.

That's OK, I'll include it in my i2c tree instead. While Linus doesn't
like it, he didn't actually provide replacement code, only a vague idea
which Thomas and myself know by experience, won't work well anyway. As
the checks done by this driver are valuable, having it in -mm and
linux-next is still good.

-- 
Jean Delvare
----------------------------------------------


If you get a conflict you should see something like this when loading
the hwmon/sensor driver:
i2c /dev entries driver
f71805f: Found F71805F/FG chip at 0x290, revision 19
ACPI: I/O resource f71805f [0x290-0x297] conflicts with ACPI region IP__ [0x295-0x296]
ACPI: Device needs an ACPI driver

   Thomas

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Jean Delvare]

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:
> On Mon, 2008-04-28 at 20:19 +0200, Kasper Sandberg wrote:
> > On Wed, 2008-04-23 at 11:43 +0300, Maxim Levitsky wrote:
> > > On Saturday, 19 April 2008 04:51:48 Len Brown wrote:
> > > > On Friday 18 April 2008, Matthew wrote:
> > > > > Hi everyone, hi Linus,
> > > > > 
> > > > > congratulations on this new great kernel-release :)
> > > > > 
> > > > > I've another "regression" to report for 2.6.25:
> > > > > 
> > > > > it's concerning much higher temperatures being read out by the
> > > > > "coretemp" kernel-module in comparison to 2.6.24* series
> > > > > 
> > > > > e.g. where temperatures were around 40-47°C they are now constantly
> > > > > jumping around 55-70°C (even in idle !)
> > > 
> > > I just updated from 2.6.24 to 2.6.25
> > > (I usually follow whole development cycle, but I was very busy, so I skipped 2.6.25 cycle)
> > > 
> > > I confirm this.
> > > I *know* that temperatures reported now are wrong.

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.

> > 
> > I too can confirm that it reports incorrect temperatures.
> > 
> > I have a Q9450, and this is my "sensors" output:
> > it8718-isa-0290
> > Adapter: ISA adapter
> > <snip>
> > temp1:       +44°C  (low  =  +127°C, high =  +127°C)   sensor = thermistor
> > temp2:       +22°C  (low  =  +127°C, high =   +60°C)   sensor = diode
> > temp3:        -2°C  (low  =  +127°C, high =  +127°C)   sensor = thermistor
> > vid:      +0.000 V
> > 
> > coretemp-isa-0000
> > Adapter: ISA adapter
> > Core 0:      +44°C  (high =  +100°C)
> > 
> > coretemp-isa-0001
> > Adapter: ISA adapter
> > Core 1:      +44°C  (high =  +100°C)
> > 
> > coretemp-isa-0002
> > Adapter: ISA adapter
> > Core 2:      +43°C  (high =  +100°C)
> > 
> > coretemp-isa-0003
> > Adapter: ISA adapter
> > Core 3:      +41°C  (high =  +100°C)
> > 
> > 
> > temp2 is the cpu temperature(matches bios), temp1 is the northbridge(i
> > think, bios says "system temp").
> > 
> > i have watercooling, and well :P when i touch the "tube", its normal
> > room temperature, and believe me, i would notice if it was 45.. this is
> > with my cpu at idle - at full load on all 4 cores, temp2 says 35, and
> > ~60 on coretemp, and THIS i would surely be able to notice over room
> > temp :)

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.

> > 
> > any progress on this bug?

I still need to be convinced that there is a bug here.

> > 
> > > 
> > > The reason is that bios did report same temperatures as coretemp in 2.6.24,
> > > moreover some time ago I have run a cpu tool (don't remember its name) on windows

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.

> > > which similar to coretemp reads from each core directly, sensor data , 
> > > and I noticed that temperature that bios reports is exactly the average 

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.

> > > temperature of both cores
> > > (I had to run this on windows - intel haven't released 
> > > drivers for their QST for temperature monitoring from bios - very sad)
> > > 
> > > And the driver did say in kernel log that TJMAX is 85C

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.

> > > 
> > > Lets at least make a kernel option to override tjmax?

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.

> Could it be that due to latest thermal changes ACPI is reading
> temperatures more often, or started to read sensors that interfere with
> libsensors?

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

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I already answered this thread while ago. I can just confirm what Jean told.

>>>> I confirm this.
>>>> I *know* that temperatures reported now are wrong.
> 
> 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.

Yes exactly. I decided to move to 0-100C scale, and move the limit too.
Of course some users with too low jumped to better scale some like you seems to
complain now.

>>> i have watercooling, and well :P when i touch the "tube", its normal
>>> room temperature, and believe me, i would notice if it was 45.. this is
>>> with my cpu at idle - at full load on all 4 cores, temp2 says 35, and
>>> ~60 on coretemp, and THIS i would surely be able to notice over room
>>> temp :)
> 
> 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.
> 
>>> any progress on this bug?
> 
> I still need to be convinced that there is a bug here.

It is not a bug, a max limit changed too, it is just matter how to scale it. The
temperature is non-physical so comparing it to physical temperature does not
make any sense. I'm sorry I did not invent this relative temp stuff - Complain
@intel. They have some calibration of TjMAX for mobiles, but this bit does not
work for desktops/servers. I tried really hard to get at LEAST some
documentation so the driver looks like it looks. And not
guessed/guessed/guessed/how it looked earlier.

> 
>>>> The reason is that bios did report same temperatures as coretemp in 2.6.24,
>>>> moreover some time ago I have run a cpu tool (don't remember its name) on windows

It was most likely coretemp - I'm in contact with the guy. We share infos.

>>>> temperature of both cores
>>>> (I had to run this on windows - intel haven't released 
>>>> drivers for their QST for temperature monitoring from bios - very sad)
>>>>
>>>> And the driver did say in kernel log that TJMAX is 85C
> 
> 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.

Well again, I tried hard at Intel and I really could not get any info on some
calibration bit. The temperature is non-physical on arbitrary scale. I changed
that so for some people it jumped to 100C, for some it remained.

>>>> Lets at least make a kernel option to override tjmax?
> 
> 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.

Well again, Intel swears there is no way how to get the TjMAX for
desktops/servers. It sucks but this is not my fault.

Thanks,
Rudolf






-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIF5203J9wPJqZRNURAnFSAKC3GpafvkviWggGJPG2o71R4lel0wCgirnW
Cr2RidnTZEdKTAj8yEviR0U=
=lFMk
-----END PGP SIGNATURE-----

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Matthew]

>
>  Hi all,
>
>  I already answered this thread while ago. I can just confirm what Jean told.
>
>
>  >>>> I confirm this.
>  >>>> I *know* that temperatures reported now are wrong.
>  >
>  > 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.
>
>  Yes exactly. I decided to move to 0-100C scale, and move the limit too.
>  Of course some users with too low jumped to better scale some like you seems to
>  complain now.
>
>
>  >>> i have watercooling, and well :P when i touch the "tube", its normal
>  >>> room temperature, and believe me, i would notice if it was 45.. this is
>  >>> with my cpu at idle - at full load on all 4 cores, temp2 says 35, and
>  >>> ~60 on coretemp, and THIS i would surely be able to notice over room
>  >>> temp :)
>  >
>  > 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.
>  >
>  >>> any progress on this bug?
>  >
>  > I still need to be convinced that there is a bug here.
>
>  It is not a bug, a max limit changed too, it is just matter how to scale it. The
>  temperature is non-physical so comparing it to physical temperature does not
>  make any sense. I'm sorry I did not invent this relative temp stuff - Complain
>  @intel. They have some calibration of TjMAX for mobiles, but this bit does not
>  work for desktops/servers. I tried really hard to get at LEAST some
>  documentation so the driver looks like it looks. And not
>  guessed/guessed/guessed/how it looked earlier.
>
>
>  >
>  >>>> The reason is that bios did report same temperatures as coretemp in 2.6.24,
>  >>>> moreover some time ago I have run a cpu tool (don't remember its name) on windows
>
>  It was most likely coretemp - I'm in contact with the guy. We share infos.
>
>
>  >>>> temperature of both cores
>  >>>> (I had to run this on windows - intel haven't released
>  >>>> drivers for their QST for temperature monitoring from bios - very sad)
>  >>>>
>  >>>> And the driver did say in kernel log that TJMAX is 85C
>  >
>  > 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.
>
>  Well again, I tried hard at Intel and I really could not get any info on some
>  calibration bit. The temperature is non-physical on arbitrary scale. I changed
>  that so for some people it jumped to 100C, for some it remained.
>
>
>  >>>> Lets at least make a kernel option to override tjmax?
>  >
>  > 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.
>
>  Well again, Intel swears there is no way how to get the TjMAX for
>  desktops/servers. It sucks but this is not my fault.
>
>  Thanks,
>  Rudolf
>


Hi Rudolf, hi @ all,

so we were just too concerned all the time & even though the
temperatures seem too high there's nothing to worry ?

I'd be more tranquilized if I had the old temperatures ;)
but like lm_sensors's output states - it's not bad until  I / we're
getting temperatures from 85°C (?) [in this particular case], ...


@lkml, Linus:

sorry for all the noise ;)



Len,

here's the output of sensors (lm_sensors):

with acpi thermal-support compiled in:

w83627ehf-isa-0290
Adapter: ISA adapter
VCore:       +1.12 V  (min =  +0.00 V, max =  +1.74 V)
in1:        +12.36 V  (min = +13.46 V, max = +13.46 V)   ALARM
AVCC:        +3.34 V  (min =  +4.08 V, max =  +2.03 V)   ALARM
3VCC:        +3.34 V  (min =  +3.92 V, max =  +3.95 V)   ALARM
in4:         +1.70 V  (min =  +1.53 V, max =  +2.04 V)
in5:         +1.59 V  (min =  +2.04 V, max =  +1.02 V)   ALARM
in6:         +5.12 V  (min =  +6.53 V, max =  +6.32 V)   ALARM
VSB:         +3.26 V  (min =  +3.06 V, max =  +4.08 V)
VBAT:        +3.20 V  (min =  +4.02 V, max =  +4.02 V)   ALARM
in9:         +1.61 V  (min =  +2.04 V, max =  +2.04 V)   ALARM
Case Fan:      0 RPM  (min =    0 RPM, div = 128)
CPU Fan:     969 RPM  (min =    0 RPM, div = 8)
Aux Fan:    3970 RPM  (min =    0 RPM, div = 2)
fan4:          0 RPM  (min =   83 RPM, div = 128)  ALARM
fan5:       1308 RPM  (min =    0 RPM, div = 8)
Sys Temp:    +39.0°C  (high = +123.0°C, hyst = -65.0°C)  sensor = thermistor
CPU Temp:    +29.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
AUX Temp:   +121.5°C  (high = +80.0°C, hyst = +75.0°C)  ALARM  sensor
= thermistor
cpu0_vid:   +1.350 V

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +60.0°C  (high = +84.0°C, crit = +100.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +57.0°C  (high = +84.0°C, crit = +100.0°C)

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

and without:

w83627ehf-isa-0290
Adapter: ISA adapter
VCore:       +1.30 V  (min =  +0.00 V, max =  +1.74 V)
in1:        +12.30 V  (min = +13.46 V, max = +13.46 V)   ALARM
AVCC:        +3.36 V  (min =  +4.08 V, max =  +2.03 V)   ALARM
3VCC:        +3.34 V  (min =  +3.92 V, max =  +3.95 V)   ALARM
in4:         +1.70 V  (min =  +1.53 V, max =  +2.04 V)
in5:         +1.59 V  (min =  +2.04 V, max =  +1.02 V)   ALARM
in6:         +5.12 V  (min =  +6.53 V, max =  +6.32 V)   ALARM
VSB:         +3.26 V  (min =  +3.06 V, max =  +4.08 V)
VBAT:        +3.20 V  (min =  +4.02 V, max =  +4.02 V)   ALARM
in9:         +1.61 V  (min =  +2.04 V, max =  +2.04 V)   ALARM
Case Fan:      0 RPM  (min =    0 RPM, div = 128)
CPU Fan:     986 RPM  (min =    0 RPM, div = 8)
Aux Fan:    3970 RPM  (min =    0 RPM, div = 2)
fan4:          0 RPM  (min =   83 RPM, div = 128)  ALARM
fan5:       1308 RPM  (min =    0 RPM, div = 8)
Sys Temp:    +39.0°C  (high = +123.0°C, hyst = -65.0°C)  sensor = thermistor
CPU Temp:    +29.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = diode
AUX Temp:   +117.0°C  (high = +80.0°C, hyst = +75.0°C)  ALARM  sensor
= thermistor
cpu0_vid:   +1.375 V

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +60.0°C  (high = +84.0°C, crit = +100.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +58.0°C  (high = +84.0°C, crit = +100.0°C)

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

it's the completely same temperatures - it had no effect on the
"correctness" of the output


thanks to everyone

Regards

Mat

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Jean Delvare]

On Wed, 30 Apr 2008 00:58:50 +0200, Matthew wrote:
> so we were just too concerned all the time & even though the
> temperatures seem too high there's nothing to worry ?

Yes.

> I'd be more tranquilized if I had the old temperatures ;)

Note that you can easily get them back by tweaking your sensors.conf
file:

chip "coretemp-*"

    compute temp1 @-15, @+15

But I wouldn't do it, as it doesn't make much sense.

> but like lm_sensors's output states - it's not bad until  I / we're
> getting temperatures from 85°C (?) [in this particular case], ...

If I remember correctly, at 84°C your CPU will start to throttle, at
100°C it will shut down. You still have 24°C before the former happens,
so it should be OK.

-- 
Jean Delvare

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Henrique de Moraes Holschuh]

On Wed, 30 Apr 2008, Jean Delvare wrote:
> On Wed, 30 Apr 2008 00:58:50 +0200, Matthew wrote:
> > so we were just too concerned all the time & even though the
> > temperatures seem too high there's nothing to worry ?
> 
> Yes.

So the big deal here is that there is no "°C" anywhere in this
measurement, it is in an arbitrary hardware scale?

> > but like lm_sensors's output states - it's not bad until  I / we're
> > getting temperatures from 85°C (?) [in this particular case], ...
> 
> If I remember correctly, at 84°C your CPU will start to throttle, at
> 100°C it will shut down. You still have 24°C before the former happens,
> so it should be OK.

Better drop the °C from there.  It starts throttling at 84 ITUs and
shuts down at 100 ITUs (Intel Thermal Units :p).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Rudolf Marek]

>>> but like lm_sensors's output states - it's not bad until  I / we're
>>> getting temperatures from 85°C (?) [in this particular case], ...
>> If I remember correctly, at 84°C your CPU will start to throttle, at
>> 100°C it will shut down. You still have 24°C before the former happens,
>> so it should be OK.

The high limit is when the all fans should go max. Throttle is at crit.

Rudolf

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Jean Delvare]

On Wed, 30 Apr 2008 16:50:59 +0200, Rudolf Marek wrote:
> >>> but like lm_sensors's output states - it's not bad until  I / we're
> >>> getting temperatures from 85°C (?) [in this particular case], ...
> >> If I remember correctly, at 84°C your CPU will start to throttle, at
> >> 100°C it will shut down. You still have 24°C before the former happens,
> >> so it should be OK.
> 
> The high limit is when the all fans should go max. Throttle is at crit.

Ah, sorry then, I remembered incorrectly.

-- 
Jean Delvare

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Pavel Machek]

Hi!

> > On Wed, 30 Apr 2008 00:58:50 +0200, Matthew wrote:
> > > so we were just too concerned all the time & even though the
> > > temperatures seem too high there's nothing to worry ?
> > 
> > Yes.
> 
> So the big deal here is that there is no "°C" anywhere in this
> measurement, it is in an arbitrary hardware scale?
> 
> > > but like lm_sensors's output states - it's not bad until  I / we're
> > > getting temperatures from 85°C (?) [in this particular case], ...
> > 
> > If I remember correctly, at 84°C your CPU will start to throttle, at
> > 100°C it will shut down. You still have 24°C before the former happens,
> > so it should be OK.
> 
> Better drop the °C from there.  It starts throttling at 84 ITUs and
> shuts down at 100 ITUs (Intel Thermal Units :p).

degrees Intel? :-)

If t1-t2 == 1ITU, is that 1degC?

> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Kasper Sandberg]

On Wed, 2008-04-30 at 00:14 +0200, Rudolf Marek wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> I already answered this thread while ago. I can just confirm what Jean told.
> 
> >>>> I confirm this.
> >>>> I *know* that temperatures reported now are wrong.
> > 
> > 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.
> 
> Yes exactly. I decided to move to 0-100C scale, and move the limit too.
> Of course some users with too low jumped to better scale some like you seems to
> complain now.
> 
> >>> i have watercooling, and well :P when i touch the "tube", its normal
> >>> room temperature, and believe me, i would notice if it was 45.. this is
> >>> with my cpu at idle - at full load on all 4 cores, temp2 says 35, and
> >>> ~60 on coretemp, and THIS i would surely be able to notice over room
> >>> temp :)
> > 
> > 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.
> > 
> >>> any progress on this bug?
> > 
> > I still need to be convinced that there is a bug here.
> 
> It is not a bug, a max limit changed too, it is just matter how to scale it. The
> temperature is non-physical so comparing it to physical temperature does not
> make any sense. I'm sorry I did not invent this relative temp stuff - Complain
> @intel. They have some calibration of TjMAX for mobiles, but this bit does not
> work for desktops/servers. I tried really hard to get at LEAST some
> documentation so the driver looks like it looks. And not
> guessed/guessed/guessed/how it looked earlier.
> 
> > 
> >>>> The reason is that bios did report same temperatures as coretemp in 2.6.24,
> >>>> moreover some time ago I have run a cpu tool (don't remember its name) on windows
> 
> It was most likely coretemp - I'm in contact with the guy. We share infos.
> 
> >>>> temperature of both cores
> >>>> (I had to run this on windows - intel haven't released 
> >>>> drivers for their QST for temperature monitoring from bios - very sad)
> >>>>
> >>>> And the driver did say in kernel log that TJMAX is 85C
> > 
> > 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.
> 
> Well again, I tried hard at Intel and I really could not get any info on some
> calibration bit. The temperature is non-physical on arbitrary scale. I changed
> that so for some people it jumped to 100C, for some it remained.

So, im confused.. The reason for this is that the internal sensor is
operating on some sort of weird scale, and thus when you interpolate it
into "your" scale, it doesent quite come out in the actual degrees
celcius the cpu temperature really is?

so if i understand this correctly, the coretemp output does NOT
represent the actual deg celcius temperature my cpu is?

> 
> >>>> Lets at least make a kernel option to override tjmax?
> > 
> > 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.
> 
> Well again, Intel swears there is no way how to get the TjMAX for
> desktops/servers. It sucks but this is not my fault.
> 
> Thanks,
> Rudolf
> 
> 
> 
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFIF5203J9wPJqZRNURAnFSAKC3GpafvkviWggGJPG2o71R4lel0wCgirnW
> Cr2RidnTZEdKTAj8yEviR0U=
> =lFMk
> -----END PGP SIGNATURE-----

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Jean Delvare]

On Wed, 30 Apr 2008 02:11:14 +0200, Kasper Sandberg wrote:
> On Wed, 2008-04-30 at 00:14 +0200, Rudolf Marek wrote:
> > Well again, I tried hard at Intel and I really could not get any info on some
> > calibration bit. The temperature is non-physical on arbitrary scale. I changed
> > that so for some people it jumped to 100C, for some it remained.
> 
> So, im confused.. The reason for this is that the internal sensor is
> operating on some sort of weird scale, and thus when you interpolate it
> into "your" scale, it doesent quite come out in the actual degrees
> celcius the cpu temperature really is?

It's really only an offset, rather than scaling. The temperature
reported by the Core and Core2 CPUs is a relative temperature. It tells
how far you are from the maximum temperature the CPU can survive. The
value is expressed in (relative) degrees C.

Rudolf did his best to find out the (absolute) temperature each CPU
model can survive (known as TJmax) so that the coretemp driver can
provide an absolute temperature to user-space, as all other hardware
monitoring drivers do. Our hope was to limit the confusion, but it
seems we failed ;) Maybe it would be better if the driver was reporting
the relative temperature value directly when we don't know the TJmax
value for sure - but then all user-space tools would need to learn how
to deal with this.

> so if i understand this correctly, the coretemp output does NOT
> represent the actual deg celcius temperature my cpu is?

It should, but there's no guarantee on desktop/server CPUs. It can be
offset by 15°C if the driver's heuristic to determine TJmax for your
CPU is incorrect. I guess the offset could even be different - after
all the documentation we got from Intel was incomplete so we don't
really know.

-- 
Jean Delvare

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Henrique de Moraes Holschuh]

On Wed, 30 Apr 2008, Jean Delvare wrote:
> On Wed, 30 Apr 2008 02:11:14 +0200, Kasper Sandberg wrote:
> > On Wed, 2008-04-30 at 00:14 +0200, Rudolf Marek wrote:
> > > Well again, I tried hard at Intel and I really could not get any info on some
> > > calibration bit. The temperature is non-physical on arbitrary scale. I changed
> > > that so for some people it jumped to 100C, for some it remained.
> > 
> > So, im confused.. The reason for this is that the internal sensor is
> > operating on some sort of weird scale, and thus when you interpolate it
> > into "your" scale, it doesent quite come out in the actual degrees
> > celcius the cpu temperature really is?
> 
> It's really only an offset, rather than scaling. The temperature
> reported by the Core and Core2 CPUs is a relative temperature. It tells
> how far you are from the maximum temperature the CPU can survive. The
> value is expressed in (relative) degrees C.

Ah, please ignore my email about ITUs (Intel thermal units), then.  The
above means 1ITU=1°C, but their zeros are at different places.

> Rudolf did his best to find out the (absolute) temperature each CPU
> model can survive (known as TJmax) so that the coretemp driver can
> provide an absolute temperature to user-space, as all other hardware
> monitoring drivers do. Our hope was to limit the confusion, but it
> seems we failed ;) Maybe it would be better if the driver was reporting
> the relative temperature value directly when we don't know the TJmax
> value for sure - but then all user-space tools would need to learn how
> to deal with this.

Actually, just libsensors would, and the local admin can adjust it at
will using the config file.

Nobody in userspace should be reading hwmon sysfs directly without the
use of libsensors.  If they are, it is their bug, and it is unsupported
AFAIK.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Jean Delvare]

On Wed, 30 Apr 2008 11:51:10 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 30 Apr 2008, Jean Delvare wrote:
> > On Wed, 30 Apr 2008 02:11:14 +0200, Kasper Sandberg wrote:
> > > So, im confused.. The reason for this is that the internal sensor is
> > > operating on some sort of weird scale, and thus when you interpolate it
> > > into "your" scale, it doesent quite come out in the actual degrees
> > > celcius the cpu temperature really is?
> > 
> > It's really only an offset, rather than scaling. The temperature
> > reported by the Core and Core2 CPUs is a relative temperature. It tells
> > how far you are from the maximum temperature the CPU can survive. The
> > value is expressed in (relative) degrees C.
> 
> Ah, please ignore my email about ITUs (Intel thermal units), then.  The
> above means 1ITU=1°C, but their zeros are at different places.
> 

Correct. 1ITU=1°C as a difference between temperatures but not as
absolute temperatures.

> > Rudolf did his best to find out the (absolute) temperature each CPU
> > model can survive (known as TJmax) so that the coretemp driver can
> > provide an absolute temperature to user-space, as all other hardware
> > monitoring drivers do. Our hope was to limit the confusion, but it
> > seems we failed ;) Maybe it would be better if the driver was reporting
> > the relative temperature value directly when we don't know the TJmax
> > value for sure - but then all user-space tools would need to learn how
> > to deal with this.
> 
> Actually, just libsensors would, and the local admin can adjust it at
> will using the config file.

Hmm, good point. I had not considered that we could hide this detail
inside libsensors. I'll need to think about it.

That being said, in practice that would probably not be too different
from just making temp1_crit writable in the coretemp driver.

> 
> Nobody in userspace should be reading hwmon sysfs directly without the
> use of libsensors.

Except for the features which are not supported by libsensors (e.g.
pwm).

> If they are, it is their bug, and it is unsupported AFAIK.

Unsupported by me, certainly, and stupid as well for sure, especially
given the amount of work that has gone into the new libsensors API to
avoid this.

-- 
Jean Delvare

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Pavel Machek]

Hi!

> > > So, im confused.. The reason for this is that the internal sensor is
> > > operating on some sort of weird scale, and thus when you interpolate it
> > > into "your" scale, it doesent quite come out in the actual degrees
> > > celcius the cpu temperature really is?
> > 
> > It's really only an offset, rather than scaling. The temperature
> > reported by the Core and Core2 CPUs is a relative temperature. It tells
> > how far you are from the maximum temperature the CPU can survive. The
> > value is expressed in (relative) degrees C.
> 
> Ah, please ignore my email about ITUs (Intel thermal units), then.  The
> above means 1ITU=1°C, but their zeros are at different places.
> 
> > Rudolf did his best to find out the (absolute) temperature each CPU
> > model can survive (known as TJmax) so that the coretemp driver can
> > provide an absolute temperature to user-space, as all other hardware
> > monitoring drivers do. Our hope was to limit the confusion, but it
> > seems we failed ;) Maybe it would be better if the driver was reporting
> > the relative temperature value directly when we don't know the TJmax
> > value for sure - but then all user-space tools would need to learn how
> > to deal with this.
> 
> Actually, just libsensors would, and the local admin can adjust it at
> will using the config file.
> 
> Nobody in userspace should be reading hwmon sysfs directly without the
> use of libsensors.  If they are, it is their bug, and it is unsupported
> AFAIK.

Hmm, that's an interesting ABI design. No, I do not think that's a
good idea.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Henrique de Moraes Holschuh]

On Fri, 02 May 2008, Pavel Machek wrote:
> > Actually, just libsensors would, and the local admin can adjust it at
> > will using the config file.
> > 
> > Nobody in userspace should be reading hwmon sysfs directly without the
> > use of libsensors.  If they are, it is their bug, and it is unsupported
> > AFAIK.
> 
> Hmm, that's an interesting ABI design. No, I do not think that's a
> good idea.

That's how it is.  The kernel drivers are to attempt to do their best to
give proper readings.  But if they don't, the library can apply
arbritary user-configurable adjustments.

I'd rather different attribute names like "raw_temp#" were used when the
adjustment thorugh libsensors is *required*, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Pavel Machek]

On Sun 2008-05-04 14:42:29, Henrique de Moraes Holschuh wrote:
> On Fri, 02 May 2008, Pavel Machek wrote:
> > > Actually, just libsensors would, and the local admin can adjust it at
> > > will using the config file.
> > > 
> > > Nobody in userspace should be reading hwmon sysfs directly without the
> > > use of libsensors.  If they are, it is their bug, and it is unsupported
> > > AFAIK.
> > 
> > Hmm, that's an interesting ABI design. No, I do not think that's a
> > good idea.
> 
> That's how it is.  The kernel drivers are to attempt to do their best to
> give proper readings.  But if they don't, the library can apply
> arbritary user-configurable adjustments.
> 
> I'd rather different attribute names like "raw_temp#" were used when the
> adjustment thorugh libsensors is *required*, though.

Yes, that would be nice.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux 2.6.25 (coretemp reads high temperatures)

[Pavel Machek]

Hi!


> > I still need to be convinced that there is a bug here.
> 
> It is not a bug, a max limit changed too, it is just matter how to scale it. The
> temperature is non-physical so comparing it to physical temperature does not
> make any sense. I'm sorry I did not invent this relative temp stuff - Complain
> @intel. They have some calibration of TjMAX for mobiles, but this bit does not
> work for desktops/servers. I tried really hard to get at LEAST some
> documentation so the driver looks like it looks. And not
> guessed/guessed/guessed/how it looked earlier.

If absolute temperature is not known, could we move it to some
obviously invalid range, so that people would not treat it as absolute
temperature?

Like, set tjmax == 0K, and report relative temperatures below 0K? Or
move it to 100-200C range, which is obviously invalid?

Or maybe invent 'relative temperature' attribute?

> >>>> Lets at least make a kernel option to override tjmax?
> > 
> > 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.
> 
> Well again, Intel swears there is no way how to get the TjMAX for
> desktops/servers. It sucks but this is not my fault.

Uff, does it differ between cpus with same stepping/etc?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Linux 2.6.25

[Linus Torvalds]

It's been long promised, but there it is now. Special thanks to Ingo who 
found and fixed a nasty-looking regression that turned out to not be a 
regression at all, but an old bug that just had not been triggering as 
reliably before.

That said, that was just the last particular regression fix I was holding 
things up for, and it's not like there weren't a lot of other fixes too, 
they just didn't end up being the final things that triggered my 
particular worries.

The full changelog from 2.6.24 is 7.5M, with a 12MB compressed patch. Tons 
and tons has changed, but if you've been following the -rc releases, 
you'll already know about the big things. The changes from the last rc 
(-rc9) are fairly small and mostly pretty trivial, and the shortlog is 
appended.

So it's mostly one-liners, with some updates to drivers (net and usb) and 
to networking that are a bit larger (although a number of the driver 
updates are things like just new ID's etc).

For those of you who haven't followed -rc's, and want the more readable 
overview of what has changed since 2.6.24, I'd suggest the usual sites, 
notably http://kernelnewbies.org/.

And a reminder for git users: while the _full_ changelogs are huge and 
unwieldly and you easily lose sight of the big picture from just bring 
overwhelmed by the details, if you're interested in some particular 
subsystem, using "gitk v2.6.24.. <path-limiter>" is a good way to see what 
has changed in that particular area.

				Linus

---
Adrian Bunk (3):
      [libata] make ali_atapi_dma static
      sh64: add missing #include <asm/fpu.h>'s
      avr32 mustn't select HAVE_IDE

Alexey Dobriyan (1):
      fbdev: fix /proc/fb oops after module removal

Alexey Korolev (1):
      JFFS2 Fix of panics caused by wrong condition for hole frag creation in write_begin

Andrew Morton (2):
      sh: arch/sh/kernel/traps_32.c needs asm/fpu.h
      sh: export empty_zero_page

Atsushi Nemoto (2):
      macb: Call phy_disconnect on removing
      macb: Use semicolon instead of comma for statement

Ayaz Abdulla (1):
      forcedeth: mac address fix

Ben Dooks (3):
      spi: spi_s3c24xx driver must init completion
      spi: spi_s3c24xx must initialize bus_num
      spi: spi_s3c24xx must initialize num_chipselect

Ben Hutchings (1):
      [NET]: Fix kernel-doc for skb_segment

Carlos Corbacho (1):
      rfkill: Fix device type check when toggling states

Chuck Ebbert (1):
      acpi: bus: check once more for an empty list after locking it

David Howells (1):
      FRV: Correctly determine the address of an illegal instruction

David S. Miller (1):
      [IPV6]: Fix ipv6 address fetching in raw6_icmp_error().

Dmitri Vorobiev (1):
      Fix typos in Documentation/filesystems/seq_file.txt

Eric Dumazet (1):
      [SOCK] sk_stamp: should be initialized to ktime_set(-1L, 0)

Greg Kroah-Hartman (1):
      USB: remove broken usb-serial num_endpoints check

Gui Jianfeng (1):
      [SCTP]: Fix protocol violation when receiving an error lenght INIT-ACK

Herton Ronaldo Krzesinski (1):
      rtl8187: Add missing priv->vif assignments

Ingo Molnar (2):
      revert "sched: fix fair sleepers"
      mm: sparsemem memory_present() fix

Ivo van Doorn (2):
      Add rfkill to MAINTAINERS file
      Update rt2x00 MAINTAINERS entry

J. Bruce Fields (1):
      locks: fix possible infinite loop in fcntl(F_SETLKW) over nfs

James Cameron (1):
      USB: Obscure Maxon BP3-USB Device Support 16d8:6280 for option driver

Jan Kara (1):
      vfs: fix possible deadlock in ext2, ext3, ext4 when using xattrs

Jarek Poplawski (2):
      [NET_SCHED] cls_u32: refcounting fix for u32_delete()
      [NET_SCHED] sch_api: fix qdisc_tree_decrease_qlen() loop

Jeff Garzik (1):
      [libata] sata_svw: fix reversed port count

Jens Axboe (2):
      io context: increment task attachment count in ioc_task_link()
      block: update git url for blktrace

Joakim Tjernlund (1):
      ucc_geth: fix non-functional fixed phy support

Johannes Berg (1):
      mac80211: remove message on receiving unexpected unencrypted frames

KOSAKI Motohiro (1):
      add "Isolate" migratetype name to /proc/pagetypeinfo

Kay Sievers (5):
      mmc: fix platform driver hotplug/coldplug
      leds: fix platform driver hotplug/coldplug
      misc: fix platform driver hotplug/coldplug
      pcmcia: fix platform driver hotplug/coldplug
      serial: fix platform driver hotplug/coldplug

Krzysztof Halasa (1):
      Mark generic HDLC + PPP as broken.

Krzysztof Helt (1):
      acpi thermal trip points increased to 12

Kyle McMartin (1):
      [PARISC] fix signal trampoline cache flushing

Laurent Pinchart (1):
      fs_enet: Don't call NAPI functions when NAPI is not used.

Li Zefan (1):
      memcg: fix oops in oom handling

Linus Torvalds (2):
      Fix locking bug in "acquire_console_semaphore_for_printk()"
      Linux 2.6.25

Manuel Lauss (1):
      sh: fix compressed kernel build

Masakazu Mokuno (1):
      PS3: gelic: fix the oops on the broken IE returned from the hypervisor

Matthias Urlichs (1):
      USB: option.c: add more device IDs

Michael Buesch (2):
      ssb: Fix usage of struct device used for DMAing
      b43legacy: Fix usage of struct device used for DMAing

Michael Ellerman (1):
      netconsole: only set CON_PRINTBUFFER if the user specifies a netconsole

Nishanth Aravamudan (1):
      Documentation: correct overcommit caveat in hugetlbpage.txt

Oliver Hartkopp (1):
      [CAN]: Update documentation of struct sockaddr_can

Patrick McHardy (3):
      [DCCP]: Fix skb->cb conflicts with IP
      [NET]: Return more appropriate error from eth_validate_addr().
      [BRIDGE]: Fix crash in __ip_route_output_key with bridge netfilter

Paul Bolle (4):
      [ISDN]: Do not validate ISDN net device address prior to interface-up
      MAINTAINERS: isdn4linux@listserv.isdn4linux.de is subscribers-only
      AFS: Do not describe debug parameters with their value
      it821x: do not describe noraid parameter with its value

Pavel Emelyanov (3):
      [AX25]: Potential ax25_uid_assoc-s leaks on module unload.
      [SCTP]: IPv4 vs IPv6 addresses mess in sctp_inet[6]addr_event.
      [NETFILTER]: ipt_CLUSTERIP: fix race between clusterip_config_find_get and _entry_put

Reinette Chatre (1):
      MAINTAINERS: move to generic repository for iwlwifi

Rusty Russell (2):
      net: make struct tun_struct private to tun.c
      net: check for underlength tap writes

Sergei Shtylyov (4):
      tg3: fix MMIO for PPC 44x platforms
      Au1200: kill IDE driver function prototypes
      Au1200: IDE driver build fix
      Pb1200/DBAu1200: fix bad IDE resource size

Sonic Zhang (1):
      smc91x driver: fix bug: print warning only in interrupt mode

Stefano Brivio (2):
      b43legacy: fix initvals loading on bcm4303
      b43legacy: fix DMA mapping leakage

Stephen Hemminger (2):
      sky2: missing chip name for Yukon Supreme
      sc92031: sysfs link missing

Thomas Klein (1):
      ehea: Fix DLPAR memory add support

Vitaliy Gusev (2):
      [TCP]: Fix never pruned tcp out-of-order queue.
      [TCP]: Add return value indication to tcp_prune_ofo_queue().

Vlad Yasevich (1):
      [SCTP]: Fix compiler warning about const qualifiers

WANG Cong (1):
      uml: compile error fix

Wei Yongjun (1):
      [SCTP]: Add check for hmac_algo parameter in sctp_verify_param()

YOSHIFUJI Hideaki (4):
      [IPV6]: IPv6 extension header structures need to be packed.
      [IPV6]: Use appropriate sock tclass setting for routing lookup.
      [IPV6] ADDRCONF: Ensure disabling multicast RS even if privacy extensions are disabled.
      [IPV6] ADDRCONF: Don't generate temporary address for ip6-ip6 interface.

Zhao Yakui (1):
      rtc: fix the error in the function of cmos_set_alarm

fangxiaozhi (1):
      USB: support more Huawei data card product IDs

tang kai (1):
      USB: option: Add new vendor ID and device ID for AMOI HSDPA modem

yakui.zhao@intel.com (1):
      acpi: unneccessary to scan the PCI bus already scanned

Re: Linux 2.6.25

[david]

On Wed, 16 Apr 2008, Linus Torvalds wrote:

> It's been long promised, but there it is now. Special thanks to Ingo who
> found and fixed a nasty-looking regression that turned out to not be a
> regression at all, but an old bug that just had not been triggering as
> reliably before.
>
> That said, that was just the last particular regression fix I was holding
> things up for, and it's not like there weren't a lot of other fixes too,
> they just didn't end up being the final things that triggered my
> particular worries.

Rafael,
   could you post the list of the remaining known regressions in 2.6.25. a 
few days ago there were about 2 dozen left, but there was a flurry of 
activity (patching, identifying some as not regressions, others as being 
fixed, etc) so I've lost track of what's left

David Lang

Re: Linux 2.6.25

[Rafael J. Wysocki]

On Thursday, 17 of April 2008, david@lang.hm wrote:
> On Wed, 16 Apr 2008, Linus Torvalds wrote:
> 
> > It's been long promised, but there it is now. Special thanks to Ingo who
> > found and fixed a nasty-looking regression that turned out to not be a
> > regression at all, but an old bug that just had not been triggering as
> > reliably before.
> >
> > That said, that was just the last particular regression fix I was holding
> > things up for, and it's not like there weren't a lot of other fixes too,
> > they just didn't end up being the final things that triggered my
> > particular worries.
> 
> Rafael,
>    could you post the list of the remaining known regressions in 2.6.25. a 
> few days ago there were about 2 dozen left, but there was a flurry of 
> activity (patching, identifying some as not regressions, others as being 
> fixed, etc) so I've lost track of what's left

Yes, I will post that later today.

Thanks,
Rafael