Allow userspace do something special on overtemp

Allow userspace do something special on overtemp

[Pavel Machek]

Hi!

This patch cleans up thermal.c a bit, and adds possibility to react to
critical overtemp: it tries to call /sbin/overtemp, and only if that
fails calls /sbin/poweroff.

Could it be applied?
								Pavel

--- tmp/linux/drivers/acpi/thermal.c	2004-08-11 10:47:04.000000000 +0200
+++ linux/drivers/acpi/thermal.c	2004-08-11 10:45:36.000000000 +0200
@@ -60,7 +60,6 @@
 #define ACPI_THERMAL_NOTIFY_HOT		0xF1
 #define ACPI_THERMAL_MODE_ACTIVE	0x00
 #define ACPI_THERMAL_MODE_PASSIVE	0x01
-#define ACPI_THERMAL_PATH_POWEROFF	"/sbin/poweroff"
 
 #define ACPI_THERMAL_MAX_ACTIVE	10
 
@@ -424,24 +423,25 @@
 
 
 static int
-acpi_thermal_call_usermode (
-	char			*path)
+acpi_thermal_call_usermode(void)
 {
 	char			*argv[2] = {NULL, NULL};
 	char			*envp[3] = {NULL, NULL, NULL};
 
 	ACPI_FUNCTION_TRACE("acpi_thermal_call_usermode");
 
-	if (!path)
-		return_VALUE(-EINVAL);
-
-	argv[0] = path;
-
 	/* minimal command environment */
 	envp[0] = "HOME=/";
 	envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
-	
-	call_usermodehelper(argv[0], argv, envp, 0);
+
+	argv[0] = "/sbin/overtemp";
+	if (call_usermodehelper(argv[0], argv, envp, 0)) {
+		argv[0] = "/sbin/poweroff";
+		if (call_usermodehelper(argv[0], argv, envp, 0)) {
+			/* What to do here? Should we just cut the power? */
+			printk(KERN_CRIT "attempts to poweroff failed, please power me down manually\n");
+		}
+	}
 
 	return_VALUE(0);
 }
@@ -483,7 +483,7 @@
 	printk(KERN_EMERG "Critical temperature reached (%ld C), shutting down.\n", KELVIN_TO_CELSIUS(tz->temperature));
 	acpi_bus_generate_event(device, ACPI_THERMAL_NOTIFY_CRITICAL, tz->trips.critical.flags.enabled);
 
-	acpi_thermal_call_usermode(ACPI_THERMAL_PATH_POWEROFF);
+	acpi_thermal_call_usermode();
 
 	return_VALUE(0);
 }


-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Allow userspace do something special on overtemp

[Arjan van de Ven]

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

On Wed, 2004-08-11 at 10:53, Pavel Machek wrote:
> Hi!
> 
> This patch cleans up thermal.c a bit, and adds possibility to react to
> critical overtemp: it tries to call /sbin/overtemp, and only if that
> fails calls /sbin/poweroff.

why not call /sbin/hotplug ????


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Allow userspace do something special on overtemp

[Pavel Machek]

Hi!

> > This patch cleans up thermal.c a bit, and adds possibility to react to
> > critical overtemp: it tries to call /sbin/overtemp, and only if that
> > fails calls /sbin/poweroff.
> 
> why not call /sbin/hotplug ????

Because /sbin/hotplug may exist, but may not know how to handle
overtemp. Which would be bad.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Allow userspace do something special on overtemp

[Måns Rullgård]

Arjan van de Ven <arjanv@redhat.com> writes:

> On Wed, 2004-08-11 at 10:53, Pavel Machek wrote:
>> Hi!
>> 
>> This patch cleans up thermal.c a bit, and adds possibility to react to
>> critical overtemp: it tries to call /sbin/overtemp, and only if that
>> fails calls /sbin/poweroff.
>
> why not call /sbin/hotplug ????

Good idea, then udev could create /dev/blowtorch so some other program
can do ioctl(SCSI_STOP) (or just run cdrecord dev=6,6,6 -eject).
Besides, it is called HOTplug for a reason.

Seriously, though, isn't hotplug supposed to handle plugging and
unplugging of hardware, rather than any random events detected by the
kernel?

-- 
Måns Rullgård
mru@kth.se

Re: Allow userspace do something special on overtemp

[Len Brown]

On Wed, 2004-08-11 at 05:06, Pavel Machek wrote:
> Hi!
> 
> > >.adds possibility to react to
> > > critical overtemp: it tries to call /sbin/overtemp, and only if
> that fails calls /sbin/poweroff.

Does /sbin/overtemp exist anyplace, or is this a proposal
to create it?  What might it do?

thanks,
-Len

Re: Allow userspace do something special on overtemp

[Wichert Akkerman]

Previously Len Brown wrote:
> Does /sbin/overtemp exist anyplace, or is this a proposal
> to create it?  What might it do?

Or why not use a netlink message for it?

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: Allow userspace do something special on overtemp

[Thomas Renninger]

Len Brown wrote:
> On Wed, 2004-08-11 at 05:06, Pavel Machek wrote:
> 
>>Hi!
>>
>>
>>>>.adds possibility to react to
>>>>critical overtemp: it tries to call /sbin/overtemp, and only if
>>
>>that fails calls /sbin/poweroff.
> 
> 
> Does /sbin/overtemp exist anyplace, or is this a proposal
> to create it?  What might it do?

save some user info, suspend, standby, extreme throttling?
It should be somehow configurable in userspace.

For my opinion it would be nicest if kernel just throws a thermal event 
to /proc/acpi/event (it already does this, but immediately shuts down) 
and acpid or others should decide whether shutdown/suspend/standby or 
whatever should be done next.
I have a machine with a broken DSDT which sets the critical tp to 200°C, 
there always must be some HW shutdown..., or do you think this is too risky?

Some other related thing:
Why are no thermal events thrown if active/passive trip points are 
reached/sub-ceeded?
The only way at the moment to figure out in userspace whether the system 
is actively cooled or even slowed down by throttling (passive) is by 
polling /proc/acpi/thermal/*/state. Isn't the purpose of thermal events 
exactly for this?
I think about a possiblity to notify user if machine is slowed down.


       Thomas

Re: Allow userspace do something special on overtemp

[Olaf Hering]

 On Wed, Aug 11, Måns Rullgård wrote:

> Seriously, though, isn't hotplug supposed to handle plugging and
> unplugging of hardware, rather than any random events detected by the
> kernel?

/sbin/kernel_event_notifier was named /sbin/hotplug by accident.
I'm sure someone will send a patch to fix it up.

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

Re: Allow userspace do something special on overtemp

[Pavel Machek]

Hi!

> Would you mind improving this slightly, instead of returning on 
> failure, idle on failure so the cpu cools down from lack of 
> instruction execution?  Is this easily done?

Well, but that would kill the system, right?

I do not want to do that. Hardware will kill us anyway if
overheat is serious.
				Pavel

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Allow userspace do something special on overtemp

[Pavel Machek]

Hi!

> > > >.adds possibility to react to
> > > > critical overtemp: it tries to call /sbin/overtemp, and only if
> > that fails calls /sbin/poweroff.
> 
> Does /sbin/overtemp exist anyplace, or is this a proposal
> to create it?  What might it do?

It does not exist anywhere, but probably will exist in SL92.

It might:
* shutdown faster (poweroff is very carefull but not too fast;
* display big red message "sorry your cpu overheated" then shutdown :-)
* do nothing (use with care if your thermal sensor is flakey)

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Allow userspace do something special on overtemp

[Kronos]

Thomas Renninger <trenn@suse.de> ha scritto:
> Len Brown wrote:
>> On Wed, 2004-08-11 at 05:06, Pavel Machek wrote:
>> 
>>>Hi!
>>>
>>>
>>>>>.adds possibility to react to
>>>>>critical overtemp: it tries to call /sbin/overtemp, and only if
>>>
>>>that fails calls /sbin/poweroff.
>> 
>> 
>> Does /sbin/overtemp exist anyplace, or is this a proposal
>> to create it?  What might it do?
> 
> save some user info, suspend, standby, extreme throttling?
> It should be somehow configurable in userspace.
> 
> For my opinion it would be nicest if kernel just throws a thermal event 
> to /proc/acpi/event (it already does this, but immediately shuts down) 
> and acpid or others should decide whether shutdown/suspend/standby or 
> whatever should be done next.

I think that /sbin/overtemp is better, acpid may not know what do.
Suppose that the kernel delivers the event to acpid (or hotplug) but
they aren't configured to handle that, your CPU will melt...

> I have a machine with a broken DSDT which sets the critical tp to 200°C, 
> there always must be some HW shutdown..., or do you think this is too risky?

It's more secure to call a program that can handle that for sure (ie.
/sbin/overtemp) and shutdown if it doesn't exist.

Luca
-- 
Home: http://kronoz.cjb.net
"New processes are created by other processes, just like new
 humans. New humans are created by other humans, of course,
 not by processes." -- Unix System Administration Handbook

Re: Allow userspace do something special on overtemp

[Dax Kelson]

On Wed, 2004-08-11 at 02:53, Pavel Machek wrote:
> Hi!
> 
> This patch cleans up thermal.c a bit, and adds possibility to react to
> critical overtemp: it tries to call /sbin/overtemp, and only if that
> fails calls /sbin/poweroff.
> 
> Could it be applied?
> 								Pavel

Why invent Yet-Another-Call-To-Userland-Interface when either
hotplug/dbus, netlink or an ACPI event will do?

The argument "well what if hotplug of acpid don't know what to do" is,
IMO, bogus since:

* Obviously systems today are functioning 
* Hardware will poweroff off on overheat anyway (not graceful, but will
save hardware components)
* Teaching hotplug/apcid isn't hard
* Policy should be kept out of the kernel if at all possible

Dax

Re: Allow userspace do something special on overtemp

[Len Brown]

I agree with Dan.

I think I'd rather see the calls to usermode deleted
instead of extended -- unless there is a reason that
the general event -> acpid method can't work.

If the administrator screws up and disables shutdown
on critical temp, modern hardware will throttle
(in hardware), and if that too fails, it will shut
itself off.

-Len

Re: Allow userspace do something special on overtemp

[Pavel Machek]

Hi!

> > This patch cleans up thermal.c a bit, and adds possibility to react to
> > critical overtemp: it tries to call /sbin/overtemp, and only if that
> > fails calls /sbin/poweroff.
> > 
> > Could it be applied?
> 
> Why invent Yet-Another-Call-To-Userland-Interface when either
> hotplug/dbus, netlink or an ACPI event will do?
> 
> The argument "well what if hotplug of acpid don't know what to do" is,
> IMO, bogus since:
> 
> * Obviously systems today are functioning 

Yes, kernel is calling /sbin/poweroff, which everyone has. Switching
to hotplug/dbus would immediately break those systems.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Allow userspace do something special on overtemp

[Pavel Machek]

Hi!

> I think I'd rather see the calls to usermode deleted
> instead of extended -- unless there is a reason that
> the general event -> acpid method can't work.

See above, switching to acpid would break all the existing
setups... in stable series.

Also notice that thermal.c is so "interestingly" written that my patch
does not actually make it longer by deleting useless defines etc...

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Allow userspace do something special on overtemp

[Len Brown]

On Thu, 2004-08-12 at 03:40, Pavel Machek wrote:
> Hi!
> 
> > I think I'd rather see the calls to usermode deleted
> > instead of extended -- unless there is a reason that
> > the general event -> acpid method can't work.
> 
> See above, switching to acpid would break all the existing
> setups... in stable series.

ah, the price of progress.

I'm confident that the distros can figure out how to
update the (neglected) acpid scripts at the same time as
(or before) the kernel update.

If they can't, then ACPI critical shutdown will fail
(maybe on some systems not such a bad thing;-)
and TM1 will kick in, and if that doesn't work, TM2
will kick in, and if that doesn't work the processor
will disable itself.

In practice, the only time this will happen is due to
an erroneous thermal sensor reading, or when somebody
loses their CPU fan; and it is the exact same path
that the system would take if somebody booted with acpi=off.

> Also notice that thermal.c is so "interestingly" written that my patch
> does not actually make it longer by deleting useless defines etc...

Conserving syntax is certainly laudable,
but conserving semantics is even more valuable.

I do thank you for identifying this issue and
proposing change.

-Len

Re: Allow userspace do something special on overtemp

[Randy.Dunlap]

On 12 Aug 2004 11:19:05 -0400 Len Brown wrote:

| Simpler to delete the usermode call and rely on the (flexible)
| acpid event, yes?
| 
|  thermal.c |   29 +----------------------------
|  1 files changed, 1 insertion(+), 28 deletions(-)

a.  Yes, it should be more flexible than just 'overtemp'.

b.  For userspace, there are:

acpid -  http://sourceforge.net/projects/acpid/

acpi tools, like ospmd (by Andy Grover) - in CVS at
  http://sourceforge.net/projects/acpi/

What others are there?

And ospmd (at least) needs some care.  Andy wanted to give it up
1 or 2 years ago, so I took it over for awhile.  However, it
still needs more care, so if anyone out there wants to maintain it,
please speak up.

--
~Randy

Re: Allow userspace do something special on overtemp

[Len Brown]

Simpler to delete the usermode call and rely on the (flexible)
acpid event, yes?

 thermal.c |   29 +----------------------------
 1 files changed, 1 insertion(+), 28 deletions(-)

cheers,
-Len


===== drivers/acpi/thermal.c 1.34 vs edited =====
--- 1.34/drivers/acpi/thermal.c	Thu Jul  8 01:56:01 2004
+++ edited/drivers/acpi/thermal.c	Thu Aug 12 11:13:59 2004
@@ -61,7 +61,6 @@
 #define ACPI_THERMAL_MODE_ACTIVE	0x00
 #define ACPI_THERMAL_MODE_PASSIVE	0x01
 #define ACPI_THERMAL_MODE_CRT   	0xff
-#define ACPI_THERMAL_PATH_POWEROFF	"/sbin/poweroff"
 
 #define ACPI_THERMAL_MAX_ACTIVE	10
 
@@ -422,30 +421,6 @@
 
 
 static int
-acpi_thermal_call_usermode (
-	char			*path)
-{
-	char			*argv[2] = {NULL, NULL};
-	char			*envp[3] = {NULL, NULL, NULL};
-
-	ACPI_FUNCTION_TRACE("acpi_thermal_call_usermode");
-
-	if (!path)
-		return_VALUE(-EINVAL);
-
-	argv[0] = path;
-
-	/* minimal command environment */
-	envp[0] = "HOME=/";
-	envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
-	
-	call_usermodehelper(argv[0], argv, envp, 0);
-
-	return_VALUE(0);
-}
-
-
-static int
 acpi_thermal_critical (
 	struct acpi_thermal	*tz)
 {
@@ -468,10 +443,8 @@
 	if (result)
 		return_VALUE(result);
 
-	printk(KERN_EMERG "Critical temperature reached (%ld C), shutting
down.\n", KELVIN_TO_CELSIUS(tz->temperature));
+	printk(KERN_EMERG "Critical temperature reached (%ld C).\n",
KELVIN_TO_CELSIUS(tz->temperature));
 	acpi_bus_generate_event(device, ACPI_THERMAL_NOTIFY_CRITICAL,
tz->trips.critical.flags.enabled);
-
-	acpi_thermal_call_usermode(ACPI_THERMAL_PATH_POWEROFF);
 
 	return_VALUE(0);
 }

Re: Allow userspace do something special on overtemp

[Stefan Seyfried]

Randy.Dunlap wrote:
> On 12 Aug 2004 11:19:05 -0400 Len Brown wrote:
> 
> | Simpler to delete the usermode call and rely on the (flexible)
> | acpid event, yes?
> | 
> |  thermal.c |   29 +----------------------------
> |  1 files changed, 1 insertion(+), 28 deletions(-)
> 
> a.  Yes, it should be more flexible than just 'overtemp'.
> 
> b.  For userspace, there are:
> 
> acpid -  http://sourceforge.net/projects/acpid/
> 
> acpi tools, like ospmd (by Andy Grover) - in CVS at
>   http://sourceforge.net/projects/acpi/
> 
> What others are there?

powersaved - http://forge.novell.com/modules/xfmod/project/?powersave
handles APM, ACPI and cpufreq
-- 
seife

"Any ideas, John?"
"Well, surrounding thems out."

Re: [ACPI] Re: Allow userspace do something special on overtemp

[Stefan Dösinger]

Hi,
Isn't this a little bit dangerous? What if acpid is not set up to handle this?

Re: Allow userspace do something special on overtemp

[Pavel Machek]

Hi!

> > > I think I'd rather see the calls to usermode deleted
> > > instead of extended -- unless there is a reason that
> > > the general event -> acpid method can't work.
> > 
> > See above, switching to acpid would break all the existing
> > setups... in stable series.
> 
> ah, the price of progress.
> 
> I'm confident that the distros can figure out how to
> update the (neglected) acpid scripts at the same time as
> (or before) the kernel update.

* not everyone is running distro

* people update their kernels more often then their distros

* not everyone wants to run acpid or equivalent (I don't, for example)

* it is still change in stable series.

* it is pretty subtle change, you are not going to notice it is broken
unless you actually run critical.

> If they can't, then ACPI critical shutdown will fail
> (maybe on some systems not such a bad thing;-)
> and TM1 will kick in, and if that doesn't work, TM2
> will kick in, and if that doesn't work the processor
> will disable itself.

hmm, yes, but it still would be nice to properly shutdown instead of
fail.
								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Allow userspace do something special on overtemp

[Len Brown]

On Thu, 2004-08-12 at 16:24, Pavel Machek wrote:
> Hi!
> 
> > > > I think I'd rather see the calls to usermode deleted
> > > > instead of extended -- unless there is a reason that
> > > > the general event -> acpid method can't work.
> > > 
> > > See above, switching to acpid would break all the existing
> > > setups... in stable series.
> > 
> > ah, the price of progress.
> > 
> > I'm confident that the distros can figure out how to
> > update the (neglected) acpid scripts at the same time as
> > (or before) the kernel update.
> 
> * not everyone is running distro
> 
> * people update their kernels more often then their distros
> 
> * not everyone wants to run acpid or equivalent (I don't, for example)
> 
> * it is still change in stable series.

> * it is pretty subtle change, you are not going to notice it is broken
> unless you actually run critical.
> 
> > If they can't, then ACPI critical shutdown will fail
> > (maybe on some systems not such a bad thing;-)
> > and TM1 will kick in, and if that doesn't work, TM2
> > will kick in, and if that doesn't work the processor
> > will disable itself.
> 
> hmm, yes, but it still would be nice to properly shutdown instead of
> fail.

The reality is that most of the critical temperature events
are false positives, and for those that are not, the hardware
will keep itself from burning even when the OS control fails.

If we confuse some self-supporting kernel types, that is too bad.
If they're supporting themselves, they should read the change logs
for the kernels that they download.  I don't think
this is of a magnitude that it needs to wait for 2.7 to be fixed.

-Len

Re: [ACPI] Re: Allow userspace do something special on overtemp

[Len Brown]

On Thu, 2004-08-12 at 13:27, Stefan Dösinger wrote:
> Hi,
> Isn't this a little bit dangerous? What if acpid is not set up to
> handle this?
> 

There are two levels of hardware thermal control that will
kick in -- TM1 and TM2, and if they fail the hardware will
turn itself off.  Speaking for Intel processors only.

The reason is that the hardware needs to handle this case
where the OS crashes while in ACPI mode and is unable
to do any thermal control itself.

cheers,
-Len

Re: Allow userspace do something special on overtemp

[Pavel Machek]

Hi!

> > hmm, yes, but it still would be nice to properly shutdown instead of
> > fail.
> 
> The reality is that most of the critical temperature events
> are false positives, and for those that are not, the hardware
> will keep itself from burning even when the OS control fails.
> 
> If we confuse some self-supporting kernel types, that is too bad.
> If they're supporting themselves, they should read the change logs
> for the kernels that they download.  I don't think
> this is of a magnitude that it needs to wait for 2.7 to be fixed.

There's nothing to fix. It is not broken. It just does /sbin/poweroff;
that's correct.

/sbin/poweroff is there on almost all systems; that is not case with
acpid. Currently *noone* has acpid that handles critical properly,
right?

So I believe that change is bad idea. /sbin/overtemp lets user
configure it etc.

Ouch and btw I've done some torturing on one prototype (AMD). It had
thermal at 98Celsius (specs for this cpu said 95C max), and I ended my
test at 105Celsius. I do not know about TM1/TM2 etc, but in this case
hardware clearly failed to do the right thing.

I do not know why acpid should be involved in this. execing binary
seems safer to me -- acpid might have died (OOM? segfault?), and exec
does not strike me like too ugly.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Allow userspace do something special on overtemp

[Robert Hancock]

----- Original Message ----- 
From: "Pavel Machek" <pavel@suse.cz>
Newsgroups: fa.linux.kernel
To: "Len Brown" <len.brown@intel.com>
Cc: "Dax Kelson" <dax@gurulabs.com>; <trenn@suse.de>; <seife@suse.de>;
"Kernel Mailing List" <linux-kernel@vger.kernel.org>
Sent: Thursday, August 12, 2004 5:25 PM
Subject: Re: Allow userspace do something special on overtemp


> Ouch and btw I've done some torturing on one prototype (AMD). It had
> thermal at 98Celsius (specs for this cpu said 95C max), and I ended my
> test at 105Celsius. I do not know about TM1/TM2 etc, but in this case
> hardware clearly failed to do the right thing.

This is dependent on the CPU/motherboard in use - AMD CPUs (up to the last
ones I heard about, anyway) don't have any built in thermal protection, they
rely on the motherboard to shut down the CPU in the event of
over-temperature. Intel CPUs since the Pentium II all shut down on excessive
over-temperature; Pentium 4s will also clock-throttle to continue operating
before they get to this point.