Re: constant processor 0x80 events

['Faye Pearson' <faye-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>]

Adachi, Kenichi [aileenja-dTzOdQ2U+/YAvxtiuMwx3w@public.gmane.org] wrote:
> Your system board triggers GPE upon some hardware condition (most likely
> thermal in your case) and GPE handler for that event (run by OS) issues
> Notify 0x80 on processor object. This eventually causes OS to reevaluate
> your _PPC object to flip the highest performance state (P-State) of your
> processor and update the supported P-State table.

So the OS should be switching the processor to the lower speedstep
setting?  It isn't AFAICS.  Also it is quite impossible to do so manually once
this situation has occurred.  I assume because the constant GPE handling
is holding onto a mutex which prevents its use - the downside of
threading this?

> I suspect that, on your machine, first current temperature crosses the
> trip point (not for passive/active cooling but for P-State update), the
> newly selected lower P-State cools down the box for a while, but sooner
> or later it starts to heat again, ending up under the "yo-yo" situation.
> This might bring about high CPU demand for repeated event handling.  

The P State is never changed from it's highest setting at least from
what I can see in proc/acpi/processor/CPU0/performance.

> > I added this CHTR call (it wasn't being called before) and 
> > that seems to stave off the problem for a while.. while 
> > programs are running, there isn't a steady rise in 
> > temperature, the temperature is seemingly all over the place. 
> >  It will get up to 82 and then suddenly drop to 59. Even when 
> > the load is going mad now, the fan is only on its high, not 
> > critical level.
> > 
> It looks to me like your CHTR ("CH"ange "TR"ip point?) method adjusts
> (enable/disable) trip point for P-State update depending on the passed
> Arg0 and the caller of this CHTR Method is expected to pass current
> temperature. If so, adding a call to CHTR in _TMP could make sense to
> some extent. It dynamically changes trip point for P-State update and
> somehow keeps box from overheating, resulting in the cooler and quiet
> environment. But we can't be sure unless we have input from BIOS writer.

It seems to update a couple of variables depending on what the
temperature is but their meaning isn't clear to me.  I haven't noticed
limit making any difference at all.
root@marmite faye # cat /proc/acpi/processor/CPU0/limit
active limit:            P0:T0
platform limit:          P0:T0
user limit:              P0:T0
thermal limit:           P0:T0

> BTW, your BIOS seemingly doesn't support active cooling, that possibly
> means the control of FAN is done by hardware modules and not exposed to
> OS. Which make/model is your machine?

That's correct.  The fan is managed in hardware, there is no acpi fan
control.  It's a Compaq Presario 2701EA.

Thanks for your suggestions, I'd love to solve this as it's the final
remaining problem.

I'm going to try to remove the GPE from the DSDT as you suggest.


Faye

"The Schizophrenic: An Unauthorized Autobiography"


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf