RE: Tell user when ACPI is killing machine

RE: Tell user when ACPI is killing machine

[Yu, Luming]

>cpufreq is not connected to acpi thermal subsystem. Dominik has some
>patches to change that, IIRC.
Is it merged into ACPI ?

Re: Tell user when ACPI is killing machine

[Pavel Machek]

Hi!

> >cpufreq is not connected to acpi thermal subsystem. Dominik has some
> >patches to change that, IIRC.
> Is it merged into ACPI ?

Not yet, IIRC. It is pretty big patch.
								Pavel

-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: [ACPI] Re: Tell user when ACPI is killing machine

[Damien Sandras]

Hi,

I have a similar problem since test10 and test11 (2.4.23 is ok, test9 is
ok too). ACPI reports bogus temperatures and powers the machine down.

If you have a patch that could fix that problem, I'm ready to try it and
report success or failure ;)

Le jeu 04/12/2003 à 10:54, Pavel Machek a écrit :
> Hi!
> 
> > >cpufreq is not connected to acpi thermal subsystem. Dominik has some
> > >patches to change that, IIRC.
> > Is it merged into ACPI ?
> 
> Not yet, IIRC. It is pretty big patch.
> 								Pavel
-- 
 _      Damien Sandras
(o-     
//\     It-Optics s.a.
v_/_    GnomeMeeting: http://www.gnomemeeting.org/
        FOSDEM 2004:  http://www.fosdem.org
        H.323 phone:  callto:ils.seconix.com/dsandras@seconix.com

Re: [ACPI] Re: Tell user when ACPI is killing machine

[Pavel Machek]

Hi!

> I have a similar problem since test10 and test11 (2.4.23 is ok, test9 is
> ok too). ACPI reports bogus temperatures and powers the machine
> down.

> If you have a patch that could fix that problem, I'm ready to try it and
> report success or failure ;)

I have ugly workaround ("if temperature reported is > 200Celsius,
ignore it").
								Pavel

-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: [ACPI] Re: Tell user when ACPI is killing machine

[Pavel Machek]

Hi!

> >> I have a similar problem since test10 and test11 (2.4.23 is ok, test9 is
> >> ok too). ACPI reports bogus temperatures and powers the machine
> >> down.
> >
> >> If you have a patch that could fix that problem, I'm ready to try it and
> >> report success or failure ;)
> >
> > I have ugly workaround ("if temperature reported is > 200Celsius,
> > ignore it").
> 
> I'm just curious, are these (and other ACPI related) problems caused
> by bugs in Linux, or by hardware/firmware bugs?

Its hard to tell one from another without extensive debugging...
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Tell user when ACPI is killing machine

[Pavel Machek]

Hi!

> >> >cpufreq is not connected to acpi thermal subsystem. Dominik has some
> >> >patches to change that, IIRC.
> >> Is it merged into ACPI ?
> 
> >Not yet, IIRC. It is pretty big patch.
> 
> Would you please point out where they are? --Luming

In http://sourceforge.net/mailarchive/message.php?msg_id=6219572,
Dominik wrote: [This is what I was talking about; oops, google groups
does not seem to index acpi-devel :-(].
								Pavel

From: Dominik Brodowski <linux@br...>
[PATCHES 2.6] ACPI processor driver updates [idle,throttling,cpufreq,thermal]  
2003-10-06 13:00

 The following patches which
 - a) replace the broken ACPI CPUfreq driver with a better, flexible variant,
 - b) modularize the processor.c code: instead of one large file there are
      many small files.
 - c) improve passive cooling support
 - d) allow for easy adding of proper locking and ref-counting in processor.c
 have been re-diffed against linux-2.6.0-test6-bk-current and are available
 on my website. 
 Len, I'll send them to you in private e-mail for easier merging later.
 
 Please apply.
 
 	Dominik
 

http://www.brodo.de/patches/2003-10-06/acpi-2.6.0-test6-2-remove_previous_pstates_implementation
 	The previous arch/i386/kernel/cpu/cpufreq/acpi.c CPUfreq
 	driver was broken, of bad design, and needs to replaced 
 	by something better. But, as a first step, remove all 
 	parts related to P-States from ACPI code.
 
 http://www.brodo.de/patches/2003-10-06/acpi-2.6.0-test6-2-processor_submodules
 	Add a "submodule interface" to drivers/acpi/processor.c
 
 	It allows to create other "modules" which access the acpi_handle 
 	for the processor, and which get notified if the event value 
 	maches the value passed in acpi_processor_register_notify.
 
 http://www.brodo.de/patches/2003-10-06/acpi-2.6.0-test6-2-processor_perflib
 	This patch adds a new "P-States library" to drivers/acpi/
 
 	CPUfreq drivers can now easly access the contents of the 
 	_PCT and the _PSS. For example, the speedstep-centrino 
 	driver could be appended so that it passes the appropriate 
 	value to the P-States library which then evaluates _PDC, 
 	and then returns the updated _PCT and _PSS.
 
 	Also, the platform limit is now handled as a cpufreq notifier and
 	as a call to cpufreq_policy_update.
 
 http://www.brodo.de/patches/2003-10-06/acpi-2.6.0-test6-2-new_acpi_io_driver
 	This re-adds the acpi P-States I/O driver. It is much smaller,
 	leaner and cleaner.
 
 http://www.brodo.de/patches/2003-10-06/acpi-2.6.0-test6-2-idle_submodule
 	This moves the idle handler out of drivers/acpi/processor and into
 	an own module.
 
 	Even if only C1 is available, it is now used. If the user prefers the 
 	default pm_idle, he can unload processor_idle, and still have the other
 	functionality available.
 
 http://www.brodo.de/patches/2003-10-06/acpi-2.6.0-test6-2-thermal_submodule
 	This adds a new mechanism to manage passive cooling. Instead of
 	hardcoded -and partly wrong- access to CPUfreq and ACPI 
 	throttling-, add a generic mechanism which other modules can 
 	register with.
 
 http://www.brodo.de/patches/2003-10-06/acpi-2.6.0-test6-2-thermal_cpufreq
 	Use _any_ CPUfreq driver for passive cooling. Implemented by an
 	cpufreq policy notifier and cpufreq_update_policy.
  
 http://www.brodo.de/patches/2003-10-06/acpi-2.6.0-test6-2-thermal_throttling
 	Move throttling into its own submodule, and register it with the new
 	passive cooling module. Also, the now-useless "limit" interface is
 	removed.
 


 



-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

RE: Tell user when ACPI is killing machine

[Yu, Luming]

>> >cpufreq is not connected to acpi thermal subsystem. Dominik has some
>> >patches to change that, IIRC.
>> Is it merged into ACPI ?

>Not yet, IIRC. It is pretty big patch.

Would you please point out where they are? --Luming

Re: Tell user when ACPI is killing machine

[Pavel Machek]

Hi!

> > On critical overheat (or perceived critical overheat -- acpi bioses on
> > some notebooks apparently report bogus values from time to time),
> > kernel itself calls /sbin/halt *without telling anything*. User can
> > not see anything, his machine just shuts down cleanly. Bad.
> 
> Sorry if this is a bit OT, but why doesn't ACPI scale the CPU

Yep it is OT.

> frequency back instead of shutting down? This is what APM does on my
> laptop (presumably in the BIOS) but when I enable ACPI the machine
> shuts down whenever I do something CPU intensive (yes; it's a poorly
> designed laptop). I have cpufreq support (cpufreq: P4/Xeon(TM) CPU
> On-Demand Clock Modulation available). Has this kind of thing been

It should try scaling first (and it works for me (tm)), but when
temperature reaches "critical" limit it is assumed that everything
failed and shutdown is only option. (On hp omnibook even in slowest
possible mode, if you play .mpg video it overheats.)

> added since I last tried it, or do I actually have to actively set up
> cpufreq in user space to get thermally-induced clock modulation? Or is
> not even possible with the current state of things?

cpufreq is not connected to acpi thermal subsystem. Dominik has some
patches to change that, IIRC.
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Tell user when ACPI is killing machine

[Aaron Lehmann]

On Fri, Nov 28, 2003 at 03:55:58PM +0100, Pavel Machek wrote:
> On critical overheat (or perceived critical overheat -- acpi bioses on
> some notebooks apparently report bogus values from time to time),
> kernel itself calls /sbin/halt *without telling anything*. User can
> not see anything, his machine just shuts down cleanly. Bad.

Sorry if this is a bit OT, but why doesn't ACPI scale the CPU
frequency back instead of shutting down? This is what APM does on my
laptop (presumably in the BIOS) but when I enable ACPI the machine
shuts down whenever I do something CPU intensive (yes; it's a poorly
designed laptop). I have cpufreq support (cpufreq: P4/Xeon(TM) CPU
On-Demand Clock Modulation available). Has this kind of thing been
added since I last tried it, or do I actually have to actively set up
cpufreq in user space to get thermally-induced clock modulation? Or is
not even possible with the current state of things?

Re: Tell user when ACPI is killing machine

[Frederik Deweerdt]

On Fri, 2003-11-28 at 15:55, Pavel Machek wrote:
> +	printk(KERN_EMERG "Critical temperature reached (%d C), shutting down.\n", tz->temperature);
Maybe there should be a KELVIN_TO_CELSIUS conversion for
tz->temperature?

Regards,
Frederik Deweerdt
frederik.deweerdt@laposte.net

Re: Tell user when ACPI is killing machine

[Pavel Machek]

Hi!

> On critical overheat (or perceived critical overheat -- acpi bioses on
> some notebooks apparently report bogus values from time to time),
> kernel itself calls /sbin/halt *without telling anything*. User can
> not see anything, his machine just shuts down cleanly. Bad.
> 
> We should at least tell the user what is going on... 

Okay, I had two bugs in single line of code (%ld and
KELVIN_TO_CELSIUS). Sorry about that, here's better version.

								Pavel

--- clean/drivers/acpi/thermal.c	2003-07-27 22:31:09.000000000 +0200
+++ linux/drivers/acpi/thermal.c	2003-11-28 17:42:17.000000000 +0100
@@ -467,6 +474,7 @@
 	if (result)
 		return_VALUE(result);
 
+	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);


-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Tell user when ACPI is killing machine

[Pavel Machek]

Hi!

On critical overheat (or perceived critical overheat -- acpi bioses on
some notebooks apparently report bogus values from time to time),
kernel itself calls /sbin/halt *without telling anything*. User can
not see anything, his machine just shuts down cleanly. Bad.

We should at least tell the user what is going on... 

								Pavel

--- clean/drivers/acpi/thermal.c	2003-07-27 22:31:09.000000000 +0200
+++ linux/drivers/acpi/thermal.c	2003-11-25 22:27:11.000000000 +0100
@@ -467,6 +474,7 @@
 	if (result)
 		return_VALUE(result);
 
+	printk(KERN_EMERG "Critical temperature reached (%d C), shutting down.\n", tz->temperature);
 	acpi_bus_generate_event(device, ACPI_THERMAL_NOTIFY_CRITICAL, tz->trips.critical.flags.enabled);
 
 	acpi_thermal_call_usermode(ACPI_THERMAL_PATH_POWEROFF);

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]