Skip to contentSkip to conversation

constant processor 0x80 events

DISCUSSION Faye Pearson 2 participants 10 messages Dec 31, 2002 – Jan 2, 2003 8 messages not in the archive ACPI

lore
Share & tools
lore

Faye Pearson

author
#0 lore raw

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 6 lines

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.

Quoted 8 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#4 lore raw
Quoted 14 lines
Quoted 7 lines

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.

Quoted 7 lines

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

author
#5 lore raw
In reply to a message not in the archive
Quoted 5 lines · Adachi, Kenichi [aileenja-dTzOdQ2U+/[email protected]] 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?

Quoted 5 lines

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.

Quoted 8 lines
Quoted 8 lines

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.

Quoted 7 lines

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
Quoted 3 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#7 lore raw
Quoted 6 lines
Quoted 3 lines

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

Quoted 1 line

to reevaluate your _PPC object to flip the highest

performance state

Quoted 8 lines
Quoted 1 line

(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

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#10 lore raw

Faye Pearson [[email protected]] wrote:
(but forgot to cc to the list)

Quoted 10 lines
Quoted 5 lines · Adachi, Kenichi [aileenja-dTzOdQ2U+/[email protected]] 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.

Quoted 28 lines
Quoted 4 lines

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.

Quoted 3 lines

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)
}

Quoted 6 lines

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?

Quoted 8 lines
Quoted 4 lines

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?

Signature · 11 lines
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#12 lore raw
Quoted 2 lines
Quoted 2 lines

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

Quoted 4 lines
Quoted 1 line

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)

Quoted 8 lines
Quoted 8 lines

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.

Quoted 5 lines
Quoted 5 lines

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

Quoted 4 lines
Quoted 4 lines

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

author
#13 lore raw
In reply to a message not in the archive
Quoted 16 lines · Faye Pearson [[email protected]] wrote:

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

Quoted 13 lines

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.

Quoted 2 lines

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

Signature · 11 lines
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

#15 lore raw
Quoted 23 lines

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
Quoted 8 lines

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

Quoted 4 lines
Quoted 2 lines

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#17 lore raw
Quoted 6 lines · Adachi, Kenichi [aileenja-dTzOdQ2U+/[email protected]] 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.

Quoted 5 lines

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

Signature · 7 lines
Mount St. Helens should have used earth control.


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