Re: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

Re: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Joey Lee]

Thank's for Kay's comment from udev side.

Hi Thomas, 

於 四，2010-04-01 於 15:40 +0200，Kay Sievers 提到：
> > Currently, there have a bit platform provider (OEM/ODM) only return the
> > _HOT, but didn't have _CRT value. But, if _HOT S4 fail, the system
> > components might dangerous if there have no any hardware protected
> > Mechanism.
> > 
> > Thomas's idea is add a sysfs interface /sys/class/thermal/S4_capable for
> > userland to tell kernel userland component (pm-util or upower?) already
> > take the _HOT event and try to do S4.
> > 
> > How do you think about this idea?
> 
> I'm not so sure, this sounds a bit like an ad-hoc interface for a pretty
> specific problem. I would expect, it needs more integration than a
> global sysfs flag that keeps its state even when no userland process is
> taking care anymore.
> 
> The details should probably be discussed on a mailing list like
> devkit-devel@lists.freedesktop.org and the people working on the
> userspace integration side should comment on it.
> 

It's Kay's suggestion from userland side, do we need discuss with more
guys from desktop side?

Thank's a lot!
Joey Lee

--
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: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Thomas Renninger]

Hi,

On Monday 12 April 2010 04:38:14 Zhang Rui wrote:
> On Tue, 2010-03-30 at 17:23 +0800, Thomas Renninger wrote:
> > Hi,
> > 
> > this is related to:
> > commit fa80945269f312bc609e8384302f58b03c916e12
> >     ACPI thermal: Don't invalidate thermal zone if critical trip point is bad
> > and
> > commit 8b7ef6d8f16274da42344cd50746ddb1c93c25ea
> >     ACPI thermal: Check for thermal zone requirement
> > 
> > There the critical trip point is replaced with the hot trip
> > point if latest Windows OS is detected (Vista also? I think yes,
> > but need to double check).
> > 
> > This seem to get more common and it looks like Windows suggests
> > to use hot trip points for thermal emergency shutdowns (S4).
> > It looks like the default Windows thermal emergency power off is
> > S4. Thus the hot trip point is used and the critical trip point
> > is of no use anymore (and often gets replaced or is invalid).
> > 
> > As thermal emergency shut down is something urgent there is this
> > direct call /sbin/poweroff in orderly_poweroff(true) compare with
> > kernel/sys.c and drivers/thermal/thermal_sys.c
> > This won't work in above cases when BIOS writers assume the machine
> > is shut down with _HOT already and do not provide _CRT anymore.
> > 
> > My idea is to also shutdown the system on _HOT by default,
> > the same way as done if _CRT is exceeded as long as no userspace
> > explicitly set a sysfs (only one file set by thermal_sys.c somewhere
> > in /sys?).
> > Background is that S4 needs some setup (e.g. swap) or userspace hooks
> > to make sure S4 succeeds and everything (network, whatever...) is set
> > up correctly afterwards.
> > 
> > Requirement for the userspace tool setting the "do not shutdown if a
> > hot thermal event happened" would be:
> >   - Fetch the thermal hot event
> 
> We need to introduce the notification mechanism, probably via netlink,
> if we want to do this in the thermal sysfs driver.
> 
> >   - Reliably power off the system (shutdown if S4 did not succeed)
> >   - ...
> > 
> Any then introduce another sysfs attribute for each trip point, say
> "trippoint_x_mode".
Not sure whether a policy per trip point is really needed.
  - active and passive trip points should always be handled in the kernel
    Eventually notifying userspace might make sense, not sure.
  - critical should get handled in kernel as well, the current power_off
    from kernel isn't that bad and always works.
  - Hot is difficult. S4 must get initiated from userspace, but if it fails
    or especially if you miss the package(s) handling it, your machine
    will shut off hard with eventuall data loss.
> kernel driver takes default actions when the threshold is reached when
> it's set "kernel", and takes no action if it's set "user".
> users can get the hot event via netlink and take any actions they want..
> 
> On the other hand, we can do this in ACPI thermal driver as well.
> Because
> 1. netlink event has already been supported.
> 2. we can disable the kernel action of _HOT by module parameters, say
> thermal.hot=on(default, s4 or shutdown in kernel)/off(no action, no
> events)/ignore(no action, but still sends events to userspace).
> 
> we don't have any notification mechanism in the thermal sys driver
> currently. 
> So If we want to do this in the generic thermal driver, we need to
> introduce the
This was just a heads up, that critical thermal shut downs may not work
with some (a lot?) recent laptops.
IMO it's still not "that" urgent. You could get (more) data loss if your system
is switched off hard, than shut down properly (or best suspended).
HW damage must still not happen. The point Henrique brought up, with the
exploiding battery is a bit of a horror scenario that must never happen.

If I find the time, I'll have a look at the mentioned userspace tools what
is already there and come back then (also considering Henriques suggestion
of native laptop driver which may want to emergency shutdown/S4 the system
for other events than thermal ones).

Thanks for the suggestions,

    Thomas

Re: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Zhang Rui]

On Tue, 2010-03-30 at 17:23 +0800, Thomas Renninger wrote:
> Hi,
> 
> this is related to:
> commit fa80945269f312bc609e8384302f58b03c916e12
>     ACPI thermal: Don't invalidate thermal zone if critical trip point is bad
> and
> commit 8b7ef6d8f16274da42344cd50746ddb1c93c25ea
>     ACPI thermal: Check for thermal zone requirement
> 
> There the critical trip point is replaced with the hot trip
> point if latest Windows OS is detected (Vista also? I think yes,
> but need to double check).
> 
> This seem to get more common and it looks like Windows suggests
> to use hot trip points for thermal emergency shutdowns (S4).
> It looks like the default Windows thermal emergency power off is
> S4. Thus the hot trip point is used and the critical trip point
> is of no use anymore (and often gets replaced or is invalid).
> 
> As thermal emergency shut down is something urgent there is this
> direct call /sbin/poweroff in orderly_poweroff(true) compare with
> kernel/sys.c and drivers/thermal/thermal_sys.c
> This won't work in above cases when BIOS writers assume the machine
> is shut down with _HOT already and do not provide _CRT anymore.
> 
> My idea is to also shutdown the system on _HOT by default,
> the same way as done if _CRT is exceeded as long as no userspace
> explicitly set a sysfs (only one file set by thermal_sys.c somewhere
> in /sys?).
> Background is that S4 needs some setup (e.g. swap) or userspace hooks
> to make sure S4 succeeds and everything (network, whatever...) is set
> up correctly afterwards.
> 
> Requirement for the userspace tool setting the "do not shutdown if a
> hot thermal event happened" would be:
>   - Fetch the thermal hot event

We need to introduce the notification mechanism, probably via netlink,
if we want to do this in the thermal sysfs driver.

>   - Reliably power off the system (shutdown if S4 did not succeed)
>   - ...
> 
Any then introduce another sysfs attribute for each trip point, say
"trippoint_x_mode".
kernel driver takes default actions when the threshold is reached when
it's set "kernel", and takes no action if it's set "user".
users can get the hot event via netlink and take any actions they want..

On the other hand, we can do this in ACPI thermal driver as well.
Because
1. netlink event has already been supported.
2. we can disable the kernel action of _HOT by module parameters, say
thermal.hot=on(default, s4 or shutdown in kernel)/off(no action, no
events)/ignore(no action, but still sends events to userspace).

thanks,
rui






we don't have any notification mechanism in the thermal sys driver
currently. 
So If we want to do this in the generic thermal driver, we need to
introduce the 



> Comments?
> What userspace tools are candidates to implement this if this
> makes sense?
> 
> Thanks,
> 
>       Thomas

Re: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Kay Sievers]

On Thu, 2010-04-01 at 07:18 -0600, Joey Lee wrote:
> 於 二，2010-03-30 於 17:31 +0100，Thomas Renninger 提到：
> > On Tuesday 30 March 2010 18:12:40 Joey Lee wrote:
> > > 於 二，2010-03-30 於 10:23 +0100，Thomas Renninger 提到：
> > > > What userspace tools are candidates to implement this if this
> > > > makes sense?
> > > 
> > > HAL + pm-util or DeviceKit-power might the candidates. But, if there
> > > have no those component in userland, what will acpi thermal module do?
> > > Direct shutdown?
> > > And, how can kernel space know userland can do this job well? Might wait
> > > 10 seconds if system doesn't S4 or shutdown?
> > Yep, my idea is to e.g. provide:
> > /sys/class/thermal/S4_capable
> > By default you get:
> > cat /sys/class/thermal/S4_capable
> > 0
> > and the thermal driver will call the same shutdown method
> > if the hot thermal tp is reached as if the critical is reached.
> > 
> > If pm-utils does:
> > echo 1 >/sys/class/thermal/S4_capable
> > it has to make sure it picks up acpi thermal hot event and initiates
> > S4. If S4 fails for whatever reasons (no swap,
> > stroking some kernel drivers fails, unmounting file systems fails, ...),
> > it has to make sure to force a system shutdown (just call /sbin/poweroff
> > the same way the kernel does currently with a critical thermal event?).
> > Emergency shutdown is then out of kernels hand (as it is currently for HOT
> > anyway which is dangerous).

What would be the event source? pm-utils is not a process, it can't pick
stuff up, I EXPECT, unless the kernel would fork a certain binary.

> > Hmm, this is acpi specific, possibly it should be a new dir here:
> > /sys/firmware/acpi/thermal/S4_capable
> > or something else?
> > 
> 
> Your idea looks good to me, but, the DeviceKit-power will rename to
> upower,

Yes, it did already a while ago.

> We are discussing about how to handle the situtation if BIOS ACPI didn't
> return the _CRT value, and even have _HOT value, if S4 fail, what can we
> do on kernel space and userland.
> 
> _CRT value is the shutdown critical temperature
> _HOT value is the critical temperature for sleep (entry to S4)
> 
> Per ACPI spec:
> The platform vendor should define _HOT to be far enough below _CRT so as
> to allow OSPM enough time to transition the system into the S4 sleeping
> state.
> 
> Currently, there have a bit platform provider (OEM/ODM) only return the
> _HOT, but didn't have _CRT value. But, if _HOT S4 fail, the system
> components might dangerous if there have no any hardware protected
> Mechanism.
> 
> Thomas's idea is add a sysfs interface /sys/class/thermal/S4_capable for
> userland to tell kernel userland component (pm-util or upower?) already
> take the _HOT event and try to do S4.
> 
> How do you think about this idea?

I'm not so sure, this sounds a bit like an ad-hoc interface for a pretty
specific problem. I would expect, it needs more integration than a
global sysfs flag that keeps its state even when no userland process is
taking care anymore.

The details should probably be discussed on a mailing list like
devkit-devel@lists.freedesktop.org and the people working on the
userspace integration side should comment on it.

Cheers,
Kay

--
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: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Joey Lee]

Hi Thomas, 

於 二，2010-03-30 於 17:31 +0100，Thomas Renninger 提到：
> On Tuesday 30 March 2010 18:12:40 Joey Lee wrote:
> > Hi Thomas, 
> > 
> > 於 二，2010-03-30 於 10:23 +0100，Thomas Renninger 提到：
> > > Hi,
> ...
> > > Comments?
> > > What userspace tools are candidates to implement this if this
> > > makes sense?
> > > 
> > 
> > HAL + pm-util or DeviceKit-power might the candidates. But, if there
> > have no those component in userland, what will acpi thermal module do?
> > Direct shutdown?
> > And, how can kernel space know userland can do this job well? Might wait
> > 10 seconds if system doesn't S4 or shutdown?
> Yep, my idea is to e.g. provide:
> /sys/class/thermal/S4_capable
> By default you get:
> cat /sys/class/thermal/S4_capable
> 0
> and the thermal driver will call the same shutdown method
> if the hot thermal tp is reached as if the critical is reached.
> 
> If pm-utils does:
> echo 1 >/sys/class/thermal/S4_capable
> it has to make sure it picks up acpi thermal hot event and initiates
> S4. If S4 fails for whatever reasons (no swap,
> stroking some kernel drivers fails, unmounting file systems fails, ...),
> it has to make sure to force a system shutdown (just call /sbin/poweroff
> the same way the kernel does currently with a critical thermal event?).
> Emergency shutdown is then out of kernels hand (as it is currently for HOT
> anyway which is dangerous).
> 
> Hmm, this is acpi specific, possibly it should be a new dir here:
> /sys/firmware/acpi/thermal/S4_capable
> or something else?
> 

Your idea looks good to me, but, the DeviceKit-power will rename to
upower, and Kay is the udev expert.
I think will need kay's professional comment on udev side.


Hi Kay, 

We are discussing about how to handle the situtation if BIOS ACPI didn't
return the _CRT value, and even have _HOT value, if S4 fail, what can we
do on kernel space and userland.

_CRT value is the shutdown critical temperature
_HOT value is the critical temperature for sleep (entry to S4)

Per ACPI spec:
The platform vendor should define _HOT to be far enough below _CRT so as
to allow OSPM enough time to transition the system into the S4 sleeping
state.

Currently, there have a bit platform provider (OEM/ODM) only return the
_HOT, but didn't have _CRT value. But, if _HOT S4 fail, the system
components might dangerous if there have no any hardware protected
Mechanism.

Thomas's idea is add a sysfs interface /sys/class/thermal/S4_capable for
userland to tell kernel userland component (pm-util or upower?) already
take the _HOT event and try to do S4.

How do you think about this idea?


Thank's
Joey Lee

--
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: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Henrique de Moraes Holschuh]

On Tue, 30 Mar 2010, Thomas Renninger wrote:
> My idea is to also shutdown the system on _HOT by default,
> the same way as done if _CRT is exceeded as long as no userspace
> explicitly set a sysfs (only one file set by thermal_sys.c somewhere
> in /sys?).
> Background is that S4 needs some setup (e.g. swap) or userspace hooks
> to make sure S4 succeeds and everything (network, whatever...) is set
> up correctly afterwards.
> 
> Requirement for the userspace tool setting the "do not shutdown if a
> hot thermal event happened" would be:
>   - Fetch the thermal hot event
>   - Reliably power off the system (shutdown if S4 did not succeed)
>   - ...
> 
> Comments?

ThinkPads have specific alarms that would benefit from a generic interface
to report the above stuff to userspace, and to kick a S3/S4/S5 transition if
userspace fails to do something about it.

These are:

1. Emergency Thermal alarms (Lenovo tells me we should enter S3 or S4)
   - Battery alarm (very dangerous, risk of Lithium fire)
   - Sensor alarm (less dangerous, risk of permanent hardware damage)

2. Wakeup from S3 because the battery is nearly empty (enter S4 or S5)
   - Pretty much guarantees the user is !@#$#@ if we don't act on it,
     since it will cause a mess even on a hibernate-to-S3 setup
     if the user didn't tell the BIOS he does "RediSafe"...

It would be nice to have flags to tell userspace if we want any sleep, or if
we need S4/S5.

It would also be nice to have a generic way to deliver these alarms,
thinkpads have pre-alarms that should be used to notify the user before
things get too dire...

-- 
  "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: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Thomas Renninger]

On Tuesday 30 March 2010 18:12:40 Joey Lee wrote:
> Hi Thomas, 
> 
> 於 二，2010-03-30 於 10:23 +0100，Thomas Renninger 提到：
> > Hi,
...
> > Comments?
> > What userspace tools are candidates to implement this if this
> > makes sense?
> > 
> 
> HAL + pm-util or DeviceKit-power might the candidates. But, if there
> have no those component in userland, what will acpi thermal module do?
> Direct shutdown?
> And, how can kernel space know userland can do this job well? Might wait
> 10 seconds if system doesn't S4 or shutdown?
Yep, my idea is to e.g. provide:
/sys/class/thermal/S4_capable
By default you get:
cat /sys/class/thermal/S4_capable
0
and the thermal driver will call the same shutdown method
if the hot thermal tp is reached as if the critical is reached.

If pm-utils does:
echo 1 >/sys/class/thermal/S4_capable
it has to make sure it picks up acpi thermal hot event and initiates
S4. If S4 fails for whatever reasons (no swap,
stroking some kernel drivers fails, unmounting file systems fails, ...),
it has to make sure to force a system shutdown (just call /sbin/poweroff
the same way the kernel does currently with a critical thermal event?).
Emergency shutdown is then out of kernels hand (as it is currently for HOT
anyway which is dangerous).

Hmm, this is acpi specific, possibly it should be a new dir here:
/sys/firmware/acpi/thermal/S4_capable
or something else?

    Thomas
--
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: [RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Joey Lee]

Hi Thomas, 

於 二，2010-03-30 於 10:23 +0100，Thomas Renninger 提到：
> Hi,
> 
> this is related to:
> commit fa80945269f312bc609e8384302f58b03c916e12
>     ACPI thermal: Don't invalidate thermal zone if critical trip point is bad
> and
> commit 8b7ef6d8f16274da42344cd50746ddb1c93c25ea
>     ACPI thermal: Check for thermal zone requirement
> 
> There the critical trip point is replaced with the hot trip
> point if latest Windows OS is detected (Vista also? I think yes,
> but need to double check).
> 
> This seem to get more common and it looks like Windows suggests
> to use hot trip points for thermal emergency shutdowns (S4).
> It looks like the default Windows thermal emergency power off is
> S4. Thus the hot trip point is used and the critical trip point
> is of no use anymore (and often gets replaced or is invalid).
> 

Sorry, I have didn't test it on Windows 7 by myself, but got information
from ODM, the _CRT is still work on Windows 7.

And, the following is 2 point need discuss:
 - Not every OS all support S4, like: Moblin 2.x or MeeGo 1.x
 - If _HOT S4 fail, like disk full, then _CRT still very important to 
   hardware component if there have no any hardware protect mechanism.

> As thermal emergency shut down is something urgent there is this
> direct call /sbin/poweroff in orderly_poweroff(true) compare with
> kernel/sys.c and drivers/thermal/thermal_sys.c
> This won't work in above cases when BIOS writers assume the machine
> is shut down with _HOT already and do not provide _CRT anymore.
> 

Agreed! There have a bit BIOS didn't return _CRT value or return the
invalid _CRT value. We still need shutdown machine even on _HOT or _CRT.

> My idea is to also shutdown the system on _HOT by default,
> the same way as done if _CRT is exceeded as long as no userspace
> explicitly set a sysfs (only one file set by thermal_sys.c somewhere
> in /sys?).
> Background is that S4 needs some setup (e.g. swap) or userspace hooks
> to make sure S4 succeeds and everything (network, whatever...) is set
> up correctly afterwards.
> 
> Requirement for the userspace tool setting the "do not shutdown if a
> hot thermal event happened" would be:
>   - Fetch the thermal hot event
>   - Reliably power off the system (shutdown if S4 did not succeed)
>   - ...
> 
> Comments?
> What userspace tools are candidates to implement this if this
> makes sense?
> 

HAL + pm-util or DeviceKit-power might the candidates. But, if there
have no those component in userland, what will acpi thermal module do?
Direct shutdown? 
And, how can kernel space know userland can do this job well? Might wait
10 seconds if system doesn't S4 or shutdown?


Thank's
Joey Lee

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

[RFC] Shutdown on thermal HOT event if no userspace tool registered being able to do S4

[Thomas Renninger]

Hi,

this is related to:
commit fa80945269f312bc609e8384302f58b03c916e12
    ACPI thermal: Don't invalidate thermal zone if critical trip point is bad
and
commit 8b7ef6d8f16274da42344cd50746ddb1c93c25ea
    ACPI thermal: Check for thermal zone requirement

There the critical trip point is replaced with the hot trip
point if latest Windows OS is detected (Vista also? I think yes,
but need to double check).

This seem to get more common and it looks like Windows suggests
to use hot trip points for thermal emergency shutdowns (S4).
It looks like the default Windows thermal emergency power off is
S4. Thus the hot trip point is used and the critical trip point
is of no use anymore (and often gets replaced or is invalid).

As thermal emergency shut down is something urgent there is this
direct call /sbin/poweroff in orderly_poweroff(true) compare with
kernel/sys.c and drivers/thermal/thermal_sys.c
This won't work in above cases when BIOS writers assume the machine
is shut down with _HOT already and do not provide _CRT anymore.

My idea is to also shutdown the system on _HOT by default,
the same way as done if _CRT is exceeded as long as no userspace
explicitly set a sysfs (only one file set by thermal_sys.c somewhere
in /sys?).
Background is that S4 needs some setup (e.g. swap) or userspace hooks
to make sure S4 succeeds and everything (network, whatever...) is set
up correctly afterwards.

Requirement for the userspace tool setting the "do not shutdown if a
hot thermal event happened" would be:
  - Fetch the thermal hot event
  - Reliably power off the system (shutdown if S4 did not succeed)
  - ...

Comments?
What userspace tools are candidates to implement this if this
makes sense?

Thanks,

      Thomas