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

[Kay Sievers <kay.sievers@vrfy.org>]

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