RE: constant processor 0x80 events

Adachi, Kenichi
2003-01-01T13:55:05Z

> > When the machine becomes under load for a while, or is hot already
> > and the processor is under load, then the CPU time in system becomes

> > very high, /proc/acpi/event is constantly
> > printing: processor CPU0 00000080 00000000 processor CPU0
> > 00000080 00000000 processor CPU0 00000080 00000000
> >
> 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.
>
> 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.
>

A few additions:
1) Can you mask GPE pin 0 at hardware level (clearing enable bit) and/or
comment out the following 4 lines (228 - 231) from your DSDT and see if
it makes a difference?

226 Scope (_GPE)
227 {
228 //Method (_L00, 0, NotSerialized)
229 //{
230 // Notify (\_PR.CPU0, 0x80)
231 //}
232

Note:
* OS may reenable GPE pin even if you sucessfully disable it.
* Removing the GPE handler could cause unhandled interrupt storm,
although I assume OS ISR properly handles the interrupt at hardware
level before passing the control to the AML interpreter to run GPE
handler... Anyway I'll look into code some time soon.

2) Do you, by any chance, run Windows on your machine and also hit this
problem?