From: Faye Pearson <faye-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
To: "Adachi, Kenichi" <aileenja-dTzOdQ2U+/YAvxtiuMwx3w@public.gmane.org>
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: constant processor 0x80 events
Date: Thu, 2 Jan 2003 10:15:13 +0000 [thread overview]
Message-ID: <20030102101513.GA947@clara.net> (raw)
In-Reply-To: <20030101192644.GA31476-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
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
next prev parent reply other threads:[~2003-01-02 10:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-31 21:12 constant processor 0x80 events Faye Pearson
[not found] ` <20021231211259.GA28810-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
2003-01-01 12:30 ` Adachi, Kenichi
[not found] ` <000101c2b191$93b74130$2d2202d3-F8JvWDuGsZU@public.gmane.org>
2003-01-01 13:55 ` Adachi, Kenichi
2003-01-01 16:40 ` 'Faye Pearson'
[not found] ` <20030101164052.GA31172-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
2003-01-01 17:58 ` Adachi, Kenichi
[not found] ` <20030101192644.GA31476@clara.net>
[not found] ` <20030101192644.GA31476-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
2003-01-02 10:15 ` Faye Pearson [this message]
[not found] ` <20030102101513.GA947-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
2003-01-02 13:52 ` Adachi, Kenichi
2003-01-02 13:59 ` Faye Pearson
[not found] ` <20030102135937.GA9257-6JSjyQ0Qj1ReoWH0uzbU5w@public.gmane.org>
2003-01-02 17:29 ` Adachi, Kenichi
[not found] ` <000201c2b284$89a033c0$232202d3-F8JvWDuGsZU@public.gmane.org>
2003-01-02 22:03 ` Faye Pearson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030102101513.GA947@clara.net \
--to=faye-6jsjyq0qj1reowh0uzbu5w@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=aileenja-dTzOdQ2U+/YAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.