constant processor 0x80 events

constant processor 0x80 events

[Faye Pearson]

This is probably a DSDT problem but I'm bewildered as to where to look
now, so would really appreciate any advice people can offer.

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

There are constantly starting and dying kacpidp processes -
top is almost always showing 1 or 2 zombie processes (kacpidp) and the
load average sticks around 2.0.

It used to also run the fan at it's maximum RPM which I didn't feel was
healthy so I've panicked and switched it off quickly to change kernels
back to a non-acpi version which doesn't have this problem - even under
consistent heavy load.

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.

  5180                          Store (Local0, Local2)
  5181                          Multiply (Local0, 0x0A, Local1)
  5182                          Add (Local1, TBSE, Local0)
  5183                          Store ("Current Temperature K is
----------- ", Debug)
  5184                          Store (Local0, Debug)
  5185                          CHTR (Local2)
  5186                          Return (Local0)

I've put my dsdt, and the dsl (from iasl 021205) on my website at
http://dude.noc.clara.net/~faye/dsdt
http://dude.noc.clara.net/~faye/dsdt.dsl

I've never used the kernel debugger before but I'm happy to get my hands
dirty if it will help solve the problem.


Faye


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

RE: constant processor 0x80 events

[Adachi, Kenichi]

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

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


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?




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

RE: constant processor 0x80 events

[Adachi, Kenichi]

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




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

Re: constant processor 0x80 events

['Faye Pearson']

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

RE: constant processor 0x80 events

[Adachi, Kenichi]

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

Actually your _PPC first evaluates 8 bits field "THRT" defined in the
"MNVS" OpRegion created in SystemMemory, which likely holds some
information about thermal condition, and if THRT is zero, we go to Else
term, ending up no P-State change. P0 stays as the highest available
P-State. 

124              Method (_PPC, 0, NotSerialized)
125              {
126                  If (THRT)
127                  {
128                      Return (One)
129                  }
130                  Else
131                  {
132                      Return (Zero)
133                  }
134              }

5258      OperationRegion (MNVS, SystemMemory, 0x1FF73E7D, 0x20)
5259      Field (MNVS, AnyAcc, Lock, Preserve)
5260      {
5261          OSYS,   16,
5262          ACON,   8,
5263          WRK0,   1,
5264          WRK1,   1,
5265          WRK2,   1,
5266          Offset (0x04),
5267          P4EN,   8,
5268          THRT,   8
5269      }

Huum, interesting. You're seeing whole bunch of Notify 0x80 on CPU0, ---
for what reason??? What makes your system to raise GPE and what is the
expected consequence? This is a sort of Hardware/BIOS design issue and
only BIOS writer can tell us everything,,, Do you have any idea?

Anyway typical usage of 0x80 I've seen is to really update P-State table
upon AC plug-in/out, and even in this case, if Notify 0x80 rushes in a
quick succession (due to chattering for example), system may misbehave. 

Please let me know your test result and if it doesn't work out, let's
look into code to figure out the best way. It could be bug in OS code
executing GPE Handler or bug in processor driver code handling 0x80
notification or what else...



 




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

Re: constant processor 0x80 events

[Faye Pearson]

Faye Pearson [faye-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org] wrote:
(but forgot to cc to the list)

> Adachi, Kenichi [aileenja-dTzOdQ2U+/YAvxtiuMwx3w@public.gmane.org] wrote:
> > Actually your _PPC first evaluates 8 bits field "THRT" defined in the
> > "MNVS" OpRegion created in SystemMemory, which likely holds some
> > information about thermal condition, and if THRT is zero, we go to Else
> > term, ending up no P-State change. P0 stays as the highest available
> > P-State. 
> 
> THRT = Throttle?  Anyway, nothing in the DSDT updates that field.  Is
> the OS supposed to?  Perhaps that is what the OS is supposed to assert
> when it receives this message?  I hate groping in the dark :/

I've used THRT as the one shot flag in the meantime and I'll see how it
goes.

> > Huum, interesting. You're seeing whole bunch of Notify 0x80 on CPU0, ---
> > for what reason??? What makes your system to raise GPE and what is the
> > expected consequence? This is a sort of Hardware/BIOS design issue and
> > only BIOS writer can tell us everything,,, Do you have any idea?
> 
> The only time I've seen this is when the processor has been running at
> full pelt for some time - ie the CPU temp is high.  I would say that the
> processor is just trying to tell the OS to switch the processor state
> down 'cause it's hot.  Probably in the wrong way :)
> 
> I would say it's probably wrong to flood the system with these events.
> 
> Is the event being sent as quickly as it can be received?  If so then
> the action associated with the event should be run from the same thread
> or it will never be actioned.
> 
> > Anyway typical usage of 0x80 I've seen is to really update P-State table
> > upon AC plug-in/out, and even in this case, if Notify 0x80 rushes in a
> > quick succession (due to chattering for example), system may misbehave. 
> 
> Perhaps it should be a one shot, reset when the processor state changes?
> eg. in _L00
> 
> If (LNot(THRT)) {
>   Store (One, THRT)
>   Notify (\_PR.CPU0, 0x80)
> }
> 
> and in _PPC
> 
> If (THRT) {
>   Store (Zero, THRT)
>   Return (One)
> }

This is what I'm currently running with.  The thing is I'm not sure
whether that will cause any other side effects - any ideas?

> > Please let me know your test result and if it doesn't work out, let's
> > look into code to figure out the best way. It could be bug in OS code
> > executing GPE Handler or bug in processor driver code handling 0x80
> > notification or what else...
> 
> Well, it does prevent the rush of messages but I don't think that's an
> elegant solution.  How do other laptops report overheat request for
> Pstate change?



-- 
Faye Pearson,
Covert Development
ClaraNET Ltd.       Tel 020 7903 3000

Eschew obfuscation.


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

RE: constant processor 0x80 events

[Adachi, Kenichi]

>> THRT = Throttle?  Anyway, nothing in the DSDT updates that field.  Is
>> the OS supposed to?  Perhaps that is what the OS is supposed to
assert 
>> when it receives this message?  I hate groping in the dark :/
> 
> I've used THRT as the one shot flag in the meantime and I'll
> see how it goes.

"THRT = Throttle" sounds reasonable to me, too. Possibly Compaq BIOS
writer meant to make P1 the highest available P-State if CPU temp is
high && CPU is already duty-cycle throttled (Tx other than T0). I can't
be sure, though.

I also realized that nobody in your DSDT updates THRT, this could mean:
  - certain register is mapped to THRT and it will be implicitly updated
by hardware 
  or
  - Compaq (or template ASL code from Intel?) doesn't fully implement
this. 
Anyway your BIOS provides OS no information to update THRT field, in
that case OS should keep from poking around it. Only Compaq can tell you
the perfect/safest way to access it in your machine. (e.g. your hack in
DSDT could cause some side effects, or fatal system failure in the worst
case) 


>> The only time I've seen this is when the processor has been running 
>> at full pelt for some time - ie the CPU temp is high.  I would say 
>> that the processor is just trying to tell the OS to switch the 
>> processor state down 'cause it's hot.  Probably in the wrong way :)
>> 
>> I would say it's probably wrong to flood the system with these 
>> events.
>> 

Agree. Whatever the reason, what you're seeing is unexpected behavior
and it can shock Compaq BIOS writer. 

>> Is the event being sent as quickly as it can be received?  If so then

>> the action associated with the event should be run from the same 
>> thread or it will never be actioned.
>> 

But note that somehow OS can report these events to /proc entry, this
indicates it's not that much inrush. OS is always allowed to go through
the following 3 stages respectively in the different context.

1) ISR stage
+ events/evsci.c:acpi_ev_sci_handler()
  + events/evgpe.c:acpi_ev_gpe_detect()
    +                       acpi_ev_gpe_dispatch() ...
    
... calling osi.c:acpi_os_queue_for_execution() 
      to queue acpi_ev_asynch_execute_gpe_method() for later
scheduling/execution 

2) DPC stage
+ events/evgpe.c:acpi_ev_asynch_execute_gpe_method()
        :
    = parse/execute _L00 method = 
        :
    + executer/exoparg2.c:acpi_ex_opcode_2A_0T_0R()  // case
AML_NOTIFY_OP: 
      + event/evmisc.c:acpi_ev_queue_notify_request() ...

... calling osi.c:acpi_os_queue_for_execution() 
      to queue acpi_ev_notify_dispatch() for later scheduling/execution 

3) Notify handling stage (by processor driver)
+ event/evmisc.c:acpi_ev_notify_dispatch()
    :  
  + processor.c:acpi_processor_notify()  // case
ACPI_PROCESSOR_NOTIFY_PERFORMANCE:
     +                  acpi_processor_get_platform_limit()  // evaluate
_PPC
     +                  acpi_processor_apply_limit()  // we always come
here as long as the above evaluation was successful 
     +         bus.c:acpi_bus_generate_event() // insert new event enrty
("processor / CPU0 / 0x80 / (RetVal of _PPC)") to /proc/acpi/event


>> Well, it does prevent the rush of messages but I don't think that's 
>> an
>> elegant solution.  How do other laptops report overheat request for 
>> Pstate change?

Requesting OS to reevaluate _PPC for thermal reason is somewhat new
concept in my understanding. Usually new idea comes from chipset vendor
and PC vendors tend to simply follow the sample supplied from chipset
vendor. 




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

Re: constant processor 0x80 events

[Faye Pearson]

Faye Pearson [faye-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org] wrote:
> I've used THRT as the one shot flag in the meantime and I'll see how it
> goes.

> > eg. in _L00
> > 
> > If (LNot(THRT)) {
> >   Store (One, THRT)
> >   Notify (\_PR.CPU0, 0x80)
> > }
> > 
> > and in _PPC
> > 
> > If (THRT) {
> >   Store (Zero, THRT)
> >   Return (One)
> > }

This has (almost) the desired (or at least helpful) effect.

Used in combination with the autospeedstep daemon, once this threshold
has been met:

root@marmite faye # cat /proc/acpi/processor/CPU0/performance
state count:             2
active state:            P1
states:
    P0:                  1200 MHz, 20000 mW, 250 uS
   *P1:                  800 MHz, 10000 mW, 250 uS
 
The processor is switched to low power mode and autospeedstep didn't do
it:

root@marmite faye # tail /var/log/speedstep
Thu Jan  2 13:23:44 2003: max. speed mode
Thu Jan  2 13:24:01 2003: power save mode
Thu Jan  2 13:24:12 2003: max. speed mode
Thu Jan  2 13:31:19 2003: power save mode
Thu Jan  2 13:37:03 2003: max. speed mode

It still thinks it's in max. speed mode.

root@marmite faye # cat /proc/acpi/thermal_zone/THRM/temperature
temperature:             51 C

The processor is now relatively chilled, it would be nice if it would
try to trip up again, but that's for me to change in autospeedstep.

> This is what I'm currently running with.  The thing is I'm not sure
> whether that will cause any other side effects - any ideas?

Still not sure about the side effects.


Faye

-- 
Faye Pearson,
Covert Development
ClaraNET Ltd.       Tel 020 7903 3000

I am the mother of all things, and all things should wear a sweater.


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

RE: constant processor 0x80 events

[Adachi, Kenichi]

> This has (almost) the desired (or at least helpful) effect.
> 
> Used in combination with the autospeedstep daemon, once this 
> threshold has been met:
> 
> root@marmite faye # cat /proc/acpi/processor/CPU0/performance
> state count:             2
> active state:            P1
> states:
>     P0:                  1200 MHz, 20000 mW, 250 uS
>    *P1:                  800 MHz, 10000 mW, 250 uS
>  
> The processor is switched to low power mode and autospeedstep 
> didn't do
> it:
> 
> root@marmite faye # tail /var/log/speedstep
> Thu Jan  2 13:23:44 2003: max. speed mode
> Thu Jan  2 13:24:01 2003: power save mode
> Thu Jan  2 13:24:12 2003: max. speed mode
> Thu Jan  2 13:31:19 2003: power save mode
> Thu Jan  2 13:37:03 2003: max. speed mode
> 
> It still thinks it's in max. speed mode.
> 
> root@marmite faye # cat /proc/acpi/thermal_zone/THRM/temperature
> temperature:             51 C
> 
> The processor is now relatively chilled, it would be nice if 
> it would try to trip up again, but that's for me to change in 
> autospeedstep.

Do you mean, because of your hack in DSDT, your processor is forced to
be in P1 upon GPE0 and it saves you from turbulent storm of event
handlings by cooling your box? And after your processor is relatively
chilled, you (manually?) initiate P-State transition to P0 (by
autospeedstep?), since your processor stays in P1? 
Interesting...

>> This is what I'm currently running with.  The thing is I'm not sure 
>> whether that will cause any other side effects - any ideas?
> 
> Still not sure about the side effects.

Can you take a look at "BIOS-provided physical RAM map" in your dmesg
and verify MNVS OpRegion (0x20 bytes starting from 0x1FF73E7D) is within
ACPI NVS Memory? ACPI NVS is saved/restored across system sleep/wake
cycle and if THRT is in this range, any possible side effects are less
harmful, as it's not mapped to critical hardware resource. 

5258      OperationRegion (MNVS, SystemMemory, 0x1FF73E7D, 0x20)
5259      Field (MNVS, AnyAcc, Lock, Preserve)
5260      {
    :
5268          THRT,   8
5269      }




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

Re: constant processor 0x80 events

[Faye Pearson]

Adachi, Kenichi [aileenja-dTzOdQ2U+/YAvxtiuMwx3w@public.gmane.org] wrote:
> Do you mean, because of your hack in DSDT, your processor is forced to
> be in P1 upon GPE0 and it saves you from turbulent storm of event
> handlings by cooling your box? And after your processor is relatively
> chilled, you (manually?) initiate P-State transition to P0 (by
> autospeedstep?), since your processor stays in P1? 
> Interesting...

GPE0, L00 method is called, it only does anything if THRT is false.
if THRT is false, it is set to one, and stops the flood of 0x80
processor events.

The event is received by the OS which calls _PPC method.  This checks
the state of THRT and if 1, it is reset and returns one, setting the
processor to P1.

Autospeedstep sets the state to P0 if the load is above 70% but only
once it has set the load to P1 itself.

> Can you take a look at "BIOS-provided physical RAM map" in your dmesg
> and verify MNVS OpRegion (0x20 bytes starting from 0x1FF73E7D) is within
> ACPI NVS Memory? ACPI NVS is saved/restored across system sleep/wake
> cycle and if THRT is in this range, any possible side effects are less
> harmful, as it's not mapped to critical hardware resource. 

 BIOS-e820: 000000001ff73c00 - 000000001ff80000 (ACPI NVS)

That's good news.

I'll run with this for a while and see how it goes.

I had some messages a while back from someone who said he was in touch
with the BIOS people.  I'll see if I can get back in touch and find out
what they actually intended!

Thanks for all your help.


Faye

-- 
Mount St. Helens should have used earth control.


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