Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Thomas Renninger]

This came in in OpenSUSE 10.3. When we still had overriden thermal polling
frequency (what we probably will do again soon). It has been tested that
specific ThinkPads do not throw a thermal event when exceeding the passive
trip point. Even thermal polling was not enough...
As no other solution has been found meanwhile and it seems Windows is also
using a virtual passive trip point:
[Bug 10658] thermal shutdown - Dell Precision M20, Latitude D610
http://bugzilla.kernel.org/show_bug.cgi?id=10658
it would be great to get this integrated into the mainline kernel.

BTW, the patch from Matthew in above bug, will this in some way be
integerated mainline? Otherwise we'll have to maintain this one ourself.

         Thomas

From: Thomas Renninger <trenn-l3A5Bk7waGM@public.gmane.org>
Subject: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p
References: https://bugzilla.novell.com/show_bug.cgi?id=333043

---
 drivers/acpi/thermal.c |   73 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

Index: linux-2.6.25-SL110_BRANCH/drivers/acpi/thermal.c
===================================================================
--- linux-2.6.25-SL110_BRANCH.orig/drivers/acpi/thermal.c
+++ linux-2.6.25-SL110_BRANCH/drivers/acpi/thermal.c
@@ -42,6 +42,7 @@
 #include <linux/kmod.h>
 #include <linux/seq_file.h>
 #include <linux/reboot.h>
+#include <linux/dmi.h>
 #include <asm/uaccess.h>
 #include <linux/thermal.h>
 #include <acpi/acpi_bus.h>
@@ -1576,6 +1577,66 @@ static int acpi_thermal_get_info(struct
 	return 0;
 }
 
+static struct dmi_system_id thermal_psv_dmi_table[] = {
+	{
+		.ident = "IBM ThinkPad T41",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
+			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41"),
+		},
+	},
+	{
+		.ident = "IBM ThinkPad T42",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
+			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42"),
+		},
+	},
+	{
+		.ident = "IBM ThinkPad T43",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
+			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43"),
+		},
+	},
+	{
+		.ident = "IBM ThinkPad T41p",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
+			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41p"),
+		},
+	},
+	{
+		.ident = "IBM ThinkPad T42p",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
+			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42p"),
+		},
+	},
+	{
+		.ident = "IBM ThinkPad T43p",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
+			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43p"),
+		},
+	},
+	{
+		.ident = "IBM ThinkPad R40",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
+			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R40"),
+		},
+	},
+	{
+		.ident = "IBM ThinkPad R50p",
+		.matches = {
+			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
+			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R50p"),
+		},
+	},
+	{},
+};
+
 static int acpi_thermal_add(struct acpi_device *device)
 {
 	int result = 0;
@@ -1606,6 +1667,18 @@ static int acpi_thermal_add(struct acpi_
 	if (result)
 		goto free_memory;
 
+	if (dmi_check_system(thermal_psv_dmi_table)) {
+		if (tz->trips.passive.flags.valid &&
+		    tz->trips.passive.temperature > CELSIUS_TO_KELVIN(85)) {
+			printk (KERN_INFO "Adjust passive trip point from %lu"
+				" to %lu\n",
+				KELVIN_TO_CELSIUS(tz->trips.passive.temperature),
+				KELVIN_TO_CELSIUS(tz->trips.passive.temperature - 150));
+			tz->trips.passive.temperature -= 150;
+			acpi_thermal_set_polling(tz, 5);
+		}
+	}
+
 	result = acpi_thermal_add_fs(device);
 	if (result)
 		goto unregister_thermal_zone;

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Andi Kleen]

Thomas Renninger wrote:
> This came in in OpenSUSE 10.3. When we still had overriden thermal polling
> frequency (what we probably will do again soon). It has been tested that
> specific ThinkPads do not throw a thermal event when exceeding the passive
> trip point. Even thermal polling was not enough...
> As no other solution has been found meanwhile and it seems Windows is also
> using a virtual passive trip point:

Ok that would be good evidence.


> +	if (dmi_check_system(thermal_psv_dmi_table)) {
> +		if (tz->trips.passive.flags.valid &&
> +		    tz->trips.passive.temperature > CELSIUS_TO_KELVIN(85)) {
> +			printk (KERN_INFO "Adjust passive trip point from %lu"
> +				" to %lu\n",
> +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature),
> +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature - 150));
> +			tz->trips.passive.temperature -= 150;

The hardcoded temperature numbers make me a little uneasy. Also 85 - 150 
is potentially negative, which is probably not good?

-Andi

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Thomas Renninger]

On Wednesday 30 July 2008 18:17:48 Andi Kleen wrote:
> Thomas Renninger wrote:
> > This came in in OpenSUSE 10.3. When we still had overriden thermal
> > polling frequency (what we probably will do again soon). It has been
> > tested that specific ThinkPads do not throw a thermal event when
> > exceeding the passive trip point. Even thermal polling was not enough...
> > As no other solution has been found meanwhile and it seems Windows is
> > also using a virtual passive trip point:
>
> Ok that would be good evidence.
>
> > +	if (dmi_check_system(thermal_psv_dmi_table)) {
> > +		if (tz->trips.passive.flags.valid &&
> > +		    tz->trips.passive.temperature > CELSIUS_TO_KELVIN(85)) {
This makes use of the macro CELSIUS_TO_KELVIN to show the better readable 
Celsius value.
temperature is internally stored in Kelvin*10
(e.g. tz->trips.{passive,active[i],hot,critical}.temperature)
> > +			printk (KERN_INFO "Adjust passive trip point from %lu"
> > +				" to %lu\n",
> > +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature),
> > +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature - 150));
Here we show the user the real Celsius value calced back.
> > +			tz->trips.passive.temperature -= 150;
>
> The hardcoded temperature numbers make me a little uneasy. Also 85 - 150
> is potentially negative, which is probably not good?
As said, stored in Kelvin*10. If you substract 150 you substract 15 degree 
Celsius or Kelvin.
Not sure whether there is a way to nicer show that.

Therefore the latest added test by Arjan for zero values returned for _CRT 
temperature looks like that:

+               /*
+                * Treat freezing temperatures as invalid as well; some
+                * BIOSes return really low values and cause reboots at 
startup.
+                * Below zero (Celcius) values clearly aren't right for sure..
+                * ... so lets discard those as invalid.
+                */
+               if (ACPI_FAILURE(status) ||
+                               tz->trips.critical.temperature <= 2732) {

A temperature value of zero degree Celsius evaluates to 2732: (0 + 273,2K) * 
10.

      Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Henrique de Moraes Holschuh]

On Wed, 30 Jul 2008, Thomas Renninger wrote:
> frequency (what we probably will do again soon). It has been tested that
> specific ThinkPads do not throw a thermal event when exceeding the passive
> trip point. Even thermal polling was not enough...

Urgh.

> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41p"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42p"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R50p"),

Just match BIOS 1R* with VENDOR IBM.  The T40 is affected as well for sure.
It uses the same BIOS and EC firmware, it *has* to be.  And it is missing on
this list.

For IBM ThinkPads, it is *always* better to match on BIOS version than on
product version.

See here for model-BIOS table:
http://www.thinkwiki.org/wiki/BIOS_Upgrade_Downloads

and here for DMI info table:
http://www.thinkwiki.org/wiki/List_of_DMI_IDs

> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43p"),

Two possible BIOS: 1Y and 70 for the T43, and BIOS 1Y for the T43p.  Are you
sure all of these machines have the bug?  Is there a common factor in the
DSDT tables we can check to root out the buggy ones?

> +		.ident = "IBM ThinkPad R40",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R40"),
> +		},

Two possible BIOSes: 1O and 1P...  and many other ThinkPad BIOSes exist in
the time window from the 1O/1P to the 1Y.  Shouldn't all of them be suspect?

No X models have these issues? (the X models always had a slightly more
advanced BIOS, so it is indeed possible that the bug was never on that
branch of the code).

> +	if (dmi_check_system(thermal_psv_dmi_table)) {
> +		if (tz->trips.passive.flags.valid &&
> +		    tz->trips.passive.temperature > CELSIUS_TO_KELVIN(85)) {
> +			printk (KERN_INFO "Adjust passive trip point from %lu"
> +				" to %lu\n",
> +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature),
> +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature - 150));
> +			tz->trips.passive.temperature -= 150;
> +			acpi_thermal_set_polling(tz, 5);
> +		}
> +	}

If this is a safe test that won't misstrigger or cause issues, maybe just
enable it on anything with BIOS_VENDOR IBM, and PRODUCT_VERSION "ThinkPad
[TR]*" ?  None of them have CPUs that should go over 85C, 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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Thomas Renninger]

On Wednesday 30 July 2008 19:52:27 Henrique de Moraes Holschuh wrote:
> On Wed, 30 Jul 2008, Thomas Renninger wrote:
> > frequency (what we probably will do again soon). It has been tested that
> > specific ThinkPads do not throw a thermal event when exceeding the
> > passive trip point. Even thermal polling was not enough...
>
> Urgh.
>
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41p"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42p"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R50p"),
>
> Just match BIOS 1R* with VENDOR IBM.  The T40 is affected as well for sure.
> It uses the same BIOS and EC firmware, it *has* to be.  And it is missing
> on this list.
>
> For IBM ThinkPads, it is *always* better to match on BIOS version than on
> product version.
>
> See here for model-BIOS table:
> http://www.thinkwiki.org/wiki/BIOS_Upgrade_Downloads
>
> and here for DMI info table:
> http://www.thinkwiki.org/wiki/List_of_DMI_IDs
>
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43p"),
I thought they tested the T43 or T43p and it threw thermal events and did not 
shut down.
I will have a look at the bug again, I have to touch this one anyway.
Or just lower passive to around 80 C for all of them as you suggested below.

Thanks for the comments..., give me some time and I repost.

       Thomas
>
> > +	if (dmi_check_system(thermal_psv_dmi_table)) {
> > +		if (tz->trips.passive.flags.valid &&
> > +		    tz->trips.passive.temperature > CELSIUS_TO_KELVIN(85)) {
> > +			printk (KERN_INFO "Adjust passive trip point from %lu"
> > +				" to %lu\n",
> > +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature),
> > +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature - 150));
> > +			tz->trips.passive.temperature -= 150;
> > +			acpi_thermal_set_polling(tz, 5);
> > +		}
> > +	}
>
> If this is a safe test that won't misstrigger or cause issues, maybe just
> enable it on anything with BIOS_VENDOR IBM, and PRODUCT_VERSION "ThinkPad
> [TR]*" ?  None of them have CPUs that should go over 85C, AFAIK.



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: [ibm-acpi-devel] Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Chris Hanson]

I'm wondering if this thread is about something similar to a problem
I've seen.  My T61p often locks up when the outside temperature is
high or when it is humid, and the CPU temperature is high (but less
than 85C).  Is this like the symptom you're addressing?

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Zhang Rui]

On Wed, 2008-07-30 at 15:56 +0200, Thomas Renninger wrote:
> This came in in OpenSUSE 10.3. When we still had overriden thermal polling
> frequency (what we probably will do again soon). It has been tested that
> specific ThinkPads do not throw a thermal event when exceeding the passive
> trip point. Even thermal polling was not enough...
> As no other solution has been found meanwhile and it seems Windows is also
> using a virtual passive trip point:
> [Bug 10658] thermal shutdown - Dell Precision M20, Latitude D610
> http://bugzilla.kernel.org/show_bug.cgi?id=10658
> it would be great to get this integrated into the mainline kernel.
> 
> BTW, the patch from Matthew in above bug, will this in some way be
> integerated mainline? Otherwise we'll have to maintain this one ourself.

Matthew has a new patch series which implement this in the generic
thermal sysfs driver, which looks good IMO.
http://marc.info/?l=linux-acpi&m=121320356423139&w=2

will you review them?

thanks,
rui

> 
> From: Thomas Renninger <trenn@suse.de>
> Subject: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p
> References: https://bugzilla.novell.com/show_bug.cgi?id=333043
> 
> ---
>  drivers/acpi/thermal.c |   73 +++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
> 
> Index: linux-2.6.25-SL110_BRANCH/drivers/acpi/thermal.c
> ===================================================================
> --- linux-2.6.25-SL110_BRANCH.orig/drivers/acpi/thermal.c
> +++ linux-2.6.25-SL110_BRANCH/drivers/acpi/thermal.c
> @@ -42,6 +42,7 @@
>  #include <linux/kmod.h>
>  #include <linux/seq_file.h>
>  #include <linux/reboot.h>
> +#include <linux/dmi.h>
>  #include <asm/uaccess.h>
>  #include <linux/thermal.h>
>  #include <acpi/acpi_bus.h>
> @@ -1576,6 +1577,66 @@ static int acpi_thermal_get_info(struct
>  	return 0;
>  }
>  
> +static struct dmi_system_id thermal_psv_dmi_table[] = {
> +	{
> +		.ident = "IBM ThinkPad T41",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41"),
> +		},
> +	},
> +	{
> +		.ident = "IBM ThinkPad T42",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42"),
> +		},
> +	},
> +	{
> +		.ident = "IBM ThinkPad T43",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43"),
> +		},
> +	},
> +	{
> +		.ident = "IBM ThinkPad T41p",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41p"),
> +		},
> +	},
> +	{
> +		.ident = "IBM ThinkPad T42p",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42p"),
> +		},
> +	},
> +	{
> +		.ident = "IBM ThinkPad T43p",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43p"),
> +		},
> +	},
> +	{
> +		.ident = "IBM ThinkPad R40",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R40"),
> +		},
> +	},
> +	{
> +		.ident = "IBM ThinkPad R50p",
> +		.matches = {
> +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R50p"),
> +		},
> +	},
> +	{},
> +};
> +
>  static int acpi_thermal_add(struct acpi_device *device)
>  {
>  	int result = 0;
> @@ -1606,6 +1667,18 @@ static int acpi_thermal_add(struct acpi_
>  	if (result)
>  		goto free_memory;
>  
> +	if (dmi_check_system(thermal_psv_dmi_table)) {
> +		if (tz->trips.passive.flags.valid &&
> +		    tz->trips.passive.temperature > CELSIUS_TO_KELVIN(85)) {
> +			printk (KERN_INFO "Adjust passive trip point from %lu"
> +				" to %lu\n",
> +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature),
> +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature - 150));
> +			tz->trips.passive.temperature -= 150;
> +			acpi_thermal_set_polling(tz, 5);
> +		}
> +	}
> +
>  	result = acpi_thermal_add_fs(device);
>  	if (result)
>  		goto unregister_thermal_zone;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Critical temp shutdowns on ThinkPad X60 1706-GMG (was Re: [ibm-acpi-devel] Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p)

[Luca Capello]

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

Hi Henrique!

On Wed, 30 Jul 2008 19:52:27 +0200, Henrique de Moraes Holschuh wrote:
> No X models have these issues? (the X models always had a slightly more
> advanced BIOS, so it is indeed possible that the bug was never on that
> branch of the code).

I've experienced critical temp shutdowns on my X60, model 1706-GMG, BIOS
7BETD5WW (2.16).  The first I've in my /var/log/syslog dating Mar 31st
and was on a Debian sid-amd64, kernel:

  2.6.25-rc7-amd64 (Debian 2.6.25~rc7-1~experimental.1~snapshot.10974)
  (waldi@debian.org) (gcc version 4.1.3 20070718 (prerelease) (Debian
  4.1.2-14+1)) #1 SMP Thu Mar 27 07:59:01 UTC 2008

Since then, I had 18 more shutdowns caused by critical temperature, with
different kernels, up to the latest 2.6.26 (still Debian kernels, not
upstream ones).

I've now a test case which shutdowns my X60: it's a `darcs pull` process
which hangs and then the temperature raises until 128°C, so the laptop
shutdowns.

If anyone has any specific suggestion, starting from next Wednesday, Aug
6th, I can perform tests on a clean Debian sid-amd64 (if needed, I can
install an i386) and with vanilla kernels.

Thx, bye,
Gismo / Luca

[-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --]

Re: Critical temp shutdowns on ThinkPad X60 1706-GMG (was Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p)

[Thomas Renninger]

On Thursday 31 July 2008 11:44:46 Luca Capello wrote:
> Hi Henrique!
>
> On Wed, 30 Jul 2008 19:52:27 +0200, Henrique de Moraes Holschuh wrote:
> > No X models have these issues? (the X models always had a slightly more
> > advanced BIOS, so it is indeed possible that the bug was never on that
> > branch of the code).
>
> I've experienced critical temp shutdowns on my X60, model 1706-GMG, BIOS
> 7BETD5WW (2.16).  The first I've in my /var/log/syslog dating Mar 31st
> and was on a Debian sid-amd64, kernel:
>
>   2.6.25-rc7-amd64 (Debian 2.6.25~rc7-1~experimental.1~snapshot.10974)
>   (waldi@debian.org) (gcc version 4.1.3 20070718 (prerelease) (Debian
>   4.1.2-14+1)) #1 SMP Thu Mar 27 07:59:01 UTC 2008
>
> Since then, I had 18 more shutdowns caused by critical temperature, with
> different kernels, up to the latest 2.6.26 (still Debian kernels, not
> upstream ones).
>
> I've now a test case which shutdowns my X60: it's a `darcs pull` process
> which hangs and then the temperature raises until 128°C, so the laptop
> shutdowns.
>
> If anyone has any specific suggestion, starting from next Wednesday, Aug
> 6th, I can perform tests on a clean Debian sid-amd64 (if needed, I can
> install an i386) and with vanilla kernels.

You should first try to reproduce this on a mainline kernel.
Is the thermal driver loaded?

If it's a Debian specific patch..., I don't know how to bisect them but you 
should try to find out which one is the offender and post on a debian site.

If this is a mainline problem you might want to revert all _OSI(Windows) from 
OS. Or better only return true for _OSI("Windows 2006"). ThinkPads store the 
running OS in separate variables and do not use the Intel OSI template.
Therefore you likely run in untested VISTA + XP + NT + XY DSDT paths.

This currently is hardly possible, I plan to blacklist Lenovos to only return 
true for "Windows 2006", they all support Vista.
If you have a mainline kernel problem, watch the list, maybe this patch will 
help you.

     Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: Critical temp shutdowns on ThinkPad X60 1706-GMG

[Luca Capello]

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

Hi Thomas!

On Thu, 31 Jul 2008 14:39:45 +0200, Thomas Renninger wrote:
> On Thursday 31 July 2008 11:44:46 Luca Capello wrote:
>> If anyone has any specific suggestion, starting from next Wednesday, Aug
>> 6th, I can perform tests on a clean Debian sid-amd64 (if needed, I can
>> install an i386) and with vanilla kernels.
>
> You should first try to reproduce this on a mainline kernel.

I know that, and I wrote the above sentence to exactly explain why I'm
not going to give other news on this subject before at least one week.

> Is the thermal driver loaded?

Yes.

> If it's a Debian specific patch..., I don't know how to bisect them
> but you should try to find out which one is the offender and post on a
> debian site.

I know how to deal with Debian [1] ;-)

> If this is a mainline problem you might want to revert all
> _OSI(Windows) from OS. Or better only return true for _OSI("Windows
> 2006").

In this case, I'll need help.  However, since I know now how to
reproduce the problem, I also have a method to test the different
solutions.

> If you have a mainline kernel problem, watch the list, maybe this
> patch will help you.

I read the list, thanks.  I was so surprised that no one reported this
issue before and I've already planned to deal with it during
DebCamp8/DebConf8 (starting on Sunday, Aug 3rd [2]).

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://wiki.debian.org/LucaCapello
[2] http://debconf8.debconf.org

[-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --]

Re: Critical temp shutdowns on ThinkPad X60 1706-GMG

[Theodore Tso]

On Thu, Jul 31, 2008 at 03:04:03PM +0200, Luca Capello wrote:
> I read the list, thanks.  I was so surprised that no one reported this
> issue before and I've already planned to deal with it during
> DebCamp8/DebConf8 (starting on Sunday, Aug 3rd [2]).

One possibility is that it's a hardware problem; for example, it could
be that your heat sink on the CPU or GPU didn't have enough thermal
compound installed, or some such.

I have an X61s, which has a different BIOS series and a low-voltage
CPU chip, so it's not directly comparable, but I can say that I've not
had any problems even when I've loaded the CPU significantly.

Of course, I also use mainline kernels and not Debian kernels.  One
thing that you might try to do while you are at DebConf is to see if
you can find other people with the same laptop model and see if they
can duplicate the problem on their machine, so you can try varying
both the Debian/non-debian kernel, as well as trying to see if you can
reproduce the problem on multiple laptops.

Regards,

        		      	   	       - Ted

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Henrique de Moraes Holschuh]

On Wed, 30 Jul 2008, Chris Hanson wrote:
> I'm wondering if this thread is about something similar to a problem
> I've seen.  My T61p often locks up when the outside temperature is
> high or when it is humid, and the CPU temperature is high (but less
> than 85C).  Is this like the symptom you're addressing?

No.  I can't tell you why your T61p is locking up, it could be either a
hardware, firmware or softare problem.  But it is not an issue with the
termal limits on ACPI.

But DO keep an eye on *all* the thermal readings you get from thinkpad-acpi.
I have seen some ThinkPads with a defective heat sink let the GPU exceed
85°C, etc.

You should ask around in the linux-thinkpad ML and the thinkpad forums to
check if others have the same problem.

And, by all means, update your BIOS and EC firmware to the latest.

-- 
  "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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Critical temp shutdowns on ThinkPad X60 1706-GMG

[Henrique de Moraes Holschuh]

On Thu, 31 Jul 2008, Theodore Tso wrote:
> Of course, I also use mainline kernels and not Debian kernels.  One
> thing that you might try to do while you are at DebConf is to see if
> you can find other people with the same laptop model and see if they

Just a note: I will be at Debconf as well.  We can make a ThinkPad kernel
hacking party if you guys want :-)

-- 
  "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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Critical temp shutdowns on ThinkPad X60 1706-GMG

[Luca Capello]

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

Hi Ted!

On Thu, 31 Jul 2008 15:15:12 +0200, Theodore Tso wrote:
> On Thu, Jul 31, 2008 at 03:04:03PM +0200, Luca Capello wrote:
>> I read the list, thanks.  I was so surprised that no one reported this
>> issue before and I've already planned to deal with it during
>> DebCamp8/DebConf8 (starting on Sunday, Aug 3rd [2]).
>
> One possibility is that it's a hardware problem; for example, it could
> be that your heat sink on the CPU or GPU didn't have enough thermal
> compound installed, or some such.

In that case I'd try to have it repaired ;-)

> I have an X61s, which has a different BIOS series and a low-voltage
> CPU chip, so it's not directly comparable, but I can say that I've not
> had any problems even when I've loaded the CPU significantly.

OK, if you want to give a try to my test case:

  $ [install darcs]
  $ darcs get http://alioth.debian.org/~gismo/darcs-pull-bug/parenscript.upstream/
  $ darcs get http://alioth.debian.org/~gismo/darcs-pull-bug/parenscript/
  $ cd parenscript
  $ darcs pull ../parenscript.upstream/
    [choose to apply only the first patch]

At that point, darcs takes 100% of the CPU and temperature starts to
rise :-(

FWIW, the same process on a PIII-500 is running for more than 5819
*hours* and it haven't finished nor spotted an error, yet.

> Of course, I also use mainline kernels and not Debian kernels.  One
> thing that you might try to do while you are at DebConf is to see if
> you can find other people with the same laptop model and see if they
> can duplicate the problem on their machine, so you can try varying
> both the Debian/non-debian kernel, as well as trying to see if you can
> reproduce the problem on multiple laptops.

This was exactly my idea: I already know that at least another X60
Debian Developer will be at DebConf8, this is another reason I waited.

Thx, bye,
Gismo / Luca

[-- Attachment #2: Type: application/pgp-signature, Size: 314 bytes --]

Re: Critical temp shutdowns on ThinkPad X60 1706-GMG

[Theodore Tso]

On Thu, Jul 31, 2008 at 03:28:51PM +0200, Luca Capello wrote:
> OK, if you want to give a try to my test case:
> 
>   $ [install darcs]
>   $ darcs get http://alioth.debian.org/~gismo/darcs-pull-bug/parenscript.upstream/
>   $ darcs get http://alioth.debian.org/~gismo/darcs-pull-bug/parenscript/
>   $ cd parenscript
>   $ darcs pull ../parenscript.upstream/
>     [choose to apply only the first patch]
> 
> At that point, darcs takes 100% of the CPU and temperature starts to
> rise :-(

Hmm.... darcs is not impressing me as a good choice of version control
systems.  I mean, yes I'm spoiled with git being able to merge
hundreds of patches is seconds, but this is rediculous!  :-)

I've tried running for it for a while, and THM0 and THM1 are in the
80-83 degree range, but it's not going above that.  According to THM1
has a passive trip point at 96 degrees, and a critical trip point at
100 degrees, but with your test case I'm not going anywhere near that
level.

Just for yucks I tried running a second copy of your test case (since
I hae a dual-core processor), and with the second core also busy 100%,
I was able to drive the temperature up another degree or two, but that
was about it.

Regards,

							- Ted

Re: Critical temp shutdowns on ThinkPad X60 1706-GMG

[Henrique de Moraes Holschuh]

On Thu, 31 Jul 2008, Theodore Tso wrote:
> On Thu, Jul 31, 2008 at 03:28:51PM +0200, Luca Capello wrote:
> > OK, if you want to give a try to my test case:
> > 
> >   $ [install darcs]
> >   $ darcs get http://alioth.debian.org/~gismo/darcs-pull-bug/parenscript.upstream/
> >   $ darcs get http://alioth.debian.org/~gismo/darcs-pull-bug/parenscript/
> >   $ cd parenscript
> >   $ darcs pull ../parenscript.upstream/
> >     [choose to apply only the first patch]
> > 
> > At that point, darcs takes 100% of the CPU and temperature starts to
> > rise :-(
> 
> Hmm.... darcs is not impressing me as a good choice of version control
> systems.  I mean, yes I'm spoiled with git being able to merge
> hundreds of patches is seconds, but this is rediculous!  :-)
> 
> I've tried running for it for a while, and THM0 and THM1 are in the
> 80-83 degree range, but it's not going above that.  According to THM1
> has a passive trip point at 96 degrees, and a critical trip point at
> 100 degrees, but with your test case I'm not going anywhere near that
> level.
> 
> Just for yucks I tried running a second copy of your test case (since
> I hae a dual-core processor), and with the second core also busy 100%,
> I was able to drive the temperature up another degree or two, but that
> was about it.

Well, as a rule, if a recent ThinkPad needs any thermal throttling, it is in
need of repair.  There are exceptions, I suppose.

But really, IBM and Lenovo have never done a very good job on the thermal
sinks.  They break (and sometimes even ship broken from factory) too easily.
It is an extremely difficult (and expensive) thing to get perfect, so that's
not too surprising.  The design is most often good enough, but what you get
in the field often doesn't leave up to the expected design parameters due to
gaps, bad thermal interface glue, cracks in the thermal interface, and
clogged-up fans.

-- 
  "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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Thomas Renninger]

On Thursday 31 July 2008 03:02:01 Zhang Rui wrote:
> On Wed, 2008-07-30 at 15:56 +0200, Thomas Renninger wrote:
> > This came in in OpenSUSE 10.3. When we still had overriden thermal
> > polling frequency (what we probably will do again soon). It has been
> > tested that specific ThinkPads do not throw a thermal event when
> > exceeding the passive trip point. Even thermal polling was not enough...
> > As no other solution has been found meanwhile and it seems Windows is
> > also using a virtual passive trip point:
> > [Bug 10658] thermal shutdown - Dell Precision M20, Latitude D610
> > http://bugzilla.kernel.org/show_bug.cgi?id=10658
> > it would be great to get this integrated into the mainline kernel.
> >
> > BTW, the patch from Matthew in above bug, will this in some way be
> > integerated mainline? Otherwise we'll have to maintain this one ourself.
>
> Matthew has a new patch series which implement this in the generic
> thermal sysfs driver, which looks good IMO.
> http://marc.info/?l=linux-acpi&m=121320356423139&w=2
No Matthew's patch won't work here because the ThinkPads define a passive
trip point.
The reason it does not work is because:
  - temperature can rise very fast on some models (especially since some
    several years old "avoid fan noise" EC firmware update)
  - passive and critical trip points exported by BIOS are about 91 and 93
    (I do not remember the exact values, but they are close together).
  - Some models do not throw a thermal event

The patch could work if it gets extended to override the passive trip point 
exported by the BIOS if the one from BIOS is higher and polling gets 
activated then. E.g.:
critical:       93
passive:        91
forced_passive: 88 (not sure whether -5 is enough, but IMO it's very much
                    worth a try to get this generic)

-> override passive tp and enable polling

>
> will you review them?
I had a short look, but I do not know thermal_sys well yet. I try to find some 
more time later or next week.
In which status is that patch, should this go into linux-next and mainline in 
2.6.28?
I can offer to go through it at later time and also add it to our factory tree 
so that it gets more testing.

> thanks,
Thank you,

         Thomas
> rui
>
> > From: Thomas Renninger <trenn@suse.de>
> > Subject: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and
> > R50p References: https://bugzilla.novell.com/show_bug.cgi?id=333043
> >
> > ---
> >  drivers/acpi/thermal.c |   73
> > +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73
> > insertions(+)
> >
> > Index: linux-2.6.25-SL110_BRANCH/drivers/acpi/thermal.c
> > ===================================================================
> > --- linux-2.6.25-SL110_BRANCH.orig/drivers/acpi/thermal.c
> > +++ linux-2.6.25-SL110_BRANCH/drivers/acpi/thermal.c
> > @@ -42,6 +42,7 @@
> >  #include <linux/kmod.h>
> >  #include <linux/seq_file.h>
> >  #include <linux/reboot.h>
> > +#include <linux/dmi.h>
> >  #include <asm/uaccess.h>
> >  #include <linux/thermal.h>
> >  #include <acpi/acpi_bus.h>
> > @@ -1576,6 +1577,66 @@ static int acpi_thermal_get_info(struct
> >  	return 0;
> >  }
> >
> > +static struct dmi_system_id thermal_psv_dmi_table[] = {
> > +	{
> > +		.ident = "IBM ThinkPad T41",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41"),
> > +		},
> > +	},
> > +	{
> > +		.ident = "IBM ThinkPad T42",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42"),
> > +		},
> > +	},
> > +	{
> > +		.ident = "IBM ThinkPad T43",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43"),
> > +		},
> > +	},
> > +	{
> > +		.ident = "IBM ThinkPad T41p",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T41p"),
> > +		},
> > +	},
> > +	{
> > +		.ident = "IBM ThinkPad T42p",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T42p"),
> > +		},
> > +	},
> > +	{
> > +		.ident = "IBM ThinkPad T43p",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad T43p"),
> > +		},
> > +	},
> > +	{
> > +		.ident = "IBM ThinkPad R40",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R40"),
> > +		},
> > +	},
> > +	{
> > +		.ident = "IBM ThinkPad R50p",
> > +		.matches = {
> > +			DMI_MATCH(DMI_BIOS_VENDOR,"IBM"),
> > +			DMI_MATCH(DMI_PRODUCT_VERSION,"ThinkPad R50p"),
> > +		},
> > +	},
> > +	{},
> > +};
> > +
> >  static int acpi_thermal_add(struct acpi_device *device)
> >  {
> >  	int result = 0;
> > @@ -1606,6 +1667,18 @@ static int acpi_thermal_add(struct acpi_
> >  	if (result)
> >  		goto free_memory;
> >
> > +	if (dmi_check_system(thermal_psv_dmi_table)) {
> > +		if (tz->trips.passive.flags.valid &&
> > +		    tz->trips.passive.temperature > CELSIUS_TO_KELVIN(85)) {
> > +			printk (KERN_INFO "Adjust passive trip point from %lu"
> > +				" to %lu\n",
> > +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature),
> > +				KELVIN_TO_CELSIUS(tz->trips.passive.temperature - 150));
> > +			tz->trips.passive.temperature -= 150;
> > +			acpi_thermal_set_polling(tz, 5);
> > +		}
> > +	}
> > +
> >  	result = acpi_thermal_add_fs(device);
> >  	if (result)
> >  		goto unregister_thermal_zone;
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Andi Kleen]

Do we have a final patch for this yet? I assume it needs at least more
entries in the DMI list as Henrique pointed out?

-Andi

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Thomas Renninger]

On Monday 11 August 2008 13:30:05 Andi Kleen wrote:
> Do we have a final patch for this yet? I assume it needs at least more
> entries in the DMI list as Henrique pointed out?

On longterm I like to try to fix this in a more generic way:

Use Matthew's basic idea/patch of introducing a passive trip point 5 degree 
below the critical trip point and set a polling frequency.
And also (this is what covers the ThinkPads) lower the trip point if the 
passive trip point is too close to the critical one (and also set a polling 
frequency).

I expect 5 degree below critical tp is not enough, IMO it's better to use e.g. 
8-10 degree (you never want to work that close at the critical temperture) 
and do not use that high polling freq instead.

However, the patch from Matthew, Zhang pointed me to, is rather broken.
Beside a typo that prevents compilation, pointer types are mixed up (char vs 
unsigned long):
---------------
include/linux/thermal.h
struct thermal_zone_device_ops {
..
	int (*get_temp) (struct thermal_zone_device *, char *);
..
}
static void thermal_update(struct work_struct *work)
{
...
	unsigned long temp;
		tz->ops->get_temp(tz, &temp);
...
}
---------------
So Matthew's patch more looks like a suggestion/proof of concept patch.
Another bug I saw by looking over this one:
+			tz->ops->get_crit_temp(tz, &crit_temp);
+			tz->force_passive_temp = crit_temp-5000;
It must get checked whether a critical trip point exists at all.

This might also have to do with the fact that his first attempts have been 
rejected...

Anyway, I like to pick this up and improve as suggested above, what makes me 
wonder about the thermal_sys.c driver are the char* based device_ops to get 
temperatures.
All (with exception to the critical temp, which is even more weird) 
temperature handling functions return char*. This looks convenient for sysfs 
processing, but it's use should be rather rare (especially if more code gets 
added)?
Instead of char->long temperature conversions every time one gets a temp from 
the thermal_sys driver, shouldn't these functions better return long and you 
have one long->char conversion for sysfs?

If Matthew already has something newer it would be great if we could somehow 
coordinate work. Otherwise I will start over on this one. Probably beginning 
with a cleanup patch to use long for get_temp and get_trip_temp functions 
instead of using char* in struct thermal_zone_device_ops {...}.
Zhang: Would that be ok or have I overseen something?


Is this a bug in current drivers/thermal/Kconfig code:
config THERMAL_HWMON
        bool "Hardware monitoring support"
        depends on HWMON=y || HWMON=THERMAL
Should the last line be:
        depends on HWMON
?

      Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Matthew Garrett]

On Mon, Aug 11, 2008 at 02:33:22PM +0200, Thomas Renninger wrote:
> ---------------
> include/linux/thermal.h
> struct thermal_zone_device_ops {
> ..
> 	int (*get_temp) (struct thermal_zone_device *, char *);
> ..
> }

You're missing the cleanup patches for the thermal layer that I posted 
at the same time.

> So Matthew's patch more looks like a suggestion/proof of concept patch.
> Another bug I saw by looking over this one:
> +			tz->ops->get_crit_temp(tz, &crit_temp);
> +			tz->force_passive_temp = crit_temp-5000;
> It must get checked whether a critical trip point exists at all.

Yes, the return value for get_crit_temp should be checked. I think 5 
degrees is safe enough, though - I haven't been able to cause a system 
to respond too quickly at that point. The polling frequency is increased 
if the temperature gets within 5 degrees of the new passive trip point.

> This might also have to do with the fact that his first attempts have been 
> rejected...

?

> If Matthew already has something newer it would be great if we could somehow 
> coordinate work. Otherwise I will start over on this one. Probably beginning 
> with a cleanup patch to use long for get_temp and get_trip_temp functions 
> instead of using char* in struct thermal_zone_device_ops {...}.
> Zhang: Would that be ok or have I overseen something?

Like I said, that's already done.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Thomas Renninger]

On Monday 11 August 2008 14:55:19 Matthew Garrett wrote:
> On Mon, Aug 11, 2008 at 02:33:22PM +0200, Thomas Renninger wrote:
> > ---------------
> > include/linux/thermal.h
> > struct thermal_zone_device_ops {
> > ..
> > 	int (*get_temp) (struct thermal_zone_device *, char *);
> > ..
> > }
>
> You're missing the cleanup patches for the thermal layer that I posted
> at the same time.
So what is the status here, how should we proceed?
This isn't applied to any tree yet?
IMO you should send those two with below fixed and Andi could queue them on 
the test branch and keep it a while there.

I could then try to get the ThinkPad thermal shutdown fixed in a generic way 
on top.

> > So Matthew's patch more looks like a suggestion/proof of concept patch.
> > Another bug I saw by looking over this one:
> > +			tz->ops->get_crit_temp(tz, &crit_temp);
> > +			tz->force_passive_temp = crit_temp-5000;
> > It must get checked whether a critical trip point exists at all.
>
> Yes, the return value for get_crit_temp should be checked. I think 5
> degrees is safe enough, though - I haven't been able to cause a system
> to respond too quickly at that point.
The temperature of some ThinkPads can raise very quickly.
> The polling frequency is increased 
> if the temperature gets within 5 degrees of the new passive trip point.
Not sure whether this is enough, but I have some people at hand who would 
thankfully try it out if things could finally be solved for ever in mainline.

     Thomas

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Matthew Garrett]

On Mon, Aug 11, 2008 at 04:14:14PM +0200, Thomas Renninger wrote:

> So what is the status here, how should we proceed?
> This isn't applied to any tree yet?
> IMO you should send those two with below fixed and Andi could queue them on 
> the test branch and keep it a while there.

I posted them, got a small amount of feedback and no further acks. I can 
push them again.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Zhang Rui]

On Mon, 2008-08-11 at 20:33 +0800, Thomas Renninger wrote:
> Is this a bug in current drivers/thermal/Kconfig code:
> config THERMAL_HWMON
>         bool "Hardware monitoring support"
>         depends on HWMON=y || HWMON=THERMAL
> Should the last line be:
>         depends on HWMON
> ?

No, for thermal class device, hwmon I/F is not required.
And we don;t want hwmon sysfs I/F if thermal_sys is built in
while hwmon is compiled as a module.

thanks,
rui

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Andi Kleen]

Matthew Garrett wrote:
> On Mon, Aug 11, 2008 at 04:14:14PM +0200, Thomas Renninger wrote:
> 
>> So what is the status here, how should we proceed?
>> This isn't applied to any tree yet?
>> IMO you should send those two with below fixed and Andi could queue them on 
>> the test branch and keep it a while there.
> 
> I posted them, got a small amount of feedback and no further acks. I can 
> push them again.

The problem seems to be that some people report this as a regression.
So either:

- It's not actually an regression but has always been this way.
In this case it's fine to delay.

- It's an regression. Then something must have been changed. Do we know what that is?
If it's really an regression then we need a low-risk fix for .27.

-Andi

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Matthew Garrett]

On Tue, Aug 12, 2008 at 10:00:26AM +0200, Andi Kleen wrote:

> The problem seems to be that some people report this as a regression.
> So either:

Yeah. I'm unconvinced that this is the right solution for the Thinkpad 
case.

> - It's an regression. Then something must have been changed. Do we know 
> what that is?
> If it's really an regression then we need a low-risk fix for .27.

The two choices would either seem to be that the system is now running 
hotter, or that we're getting spurious temperature readings.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Zhang Rui]

On Tue, 2008-08-12 at 16:00 +0800, Andi Kleen wrote:
> Matthew Garrett wrote:
> > On Mon, Aug 11, 2008 at 04:14:14PM +0200, Thomas Renninger wrote:
> >
> >> So what is the status here, how should we proceed?
> >> This isn't applied to any tree yet?
> >> IMO you should send those two with below fixed and Andi could queue
> them on
> >> the test branch and keep it a while there.
> >
> > I posted them, got a small amount of feedback and no further acks. I
> can
> > push them again.
> 
> The problem seems to be that some people report this as a regression.

No, the problem we discussed here is not a regression.
http://bugzilla.kernel.org/show_bug.cgi?id=10658
And the patch just works for the laptops that:
1. without passive trip point
2. with a passive trip point that doesn't help because it is too close
to the critical trip point.

And it's true that there is a thermal regression reported recently,
http://bugzilla.kernel.org/show_bug.cgi?id=11281
but IMO, that's another problem and we have not root caused yet.

thanks,
rui

Re: Avoid critical temp shutdowns on specific ThinkPad T4x(p) and R50p

[Andi Kleen]

> No, the problem we discussed here is not a regression.
> http://bugzilla.kernel.org/show_bug.cgi?id=10658
> And the patch just works for the laptops that:
> 1. without passive trip point
> 2. with a passive trip point that doesn't help because it is too close
> to the critical trip point.

Ok.

> And it's true that there is a thermal regression reported recently,
> http://bugzilla.kernel.org/show_bug.cgi?id=11281
> but IMO, that's another problem and we have not root caused yet.

I was indeed thinking of that one. Probably I confused it with this one.
Thanks for the clarification.

The problem is that all the people who complained about the later
regression didn't reply to my request for more information :/
Need to somehow move forward on that one.

-Andi