From: Pavel Troller <patrol@sinus.cz>
To: Arthur Huillet <arthur.huillet@agoctrl.org>
Cc: Pavel Troller <patrol@sinus.cz>, linux-acpi@vger.kernel.org
Subject: Re: Question about AthlonXP on nforce 2 : C2-C3 states
Date: Sun, 5 Feb 2006 16:42:45 +0100 [thread overview]
Message-ID: <20060205154245.GA31112@tangens.sinus.cz> (raw)
In-Reply-To: <20060205160750.4a1c1b3e.arthur.huillet@agoctrl.org>
> Hi,
>
> > If you will see more than 100 in the first line and more than 1000 in the second one, your
> > Cx states are blocked by BIOS.
>
> I'm getting 101 and 1001 indeed :
> P_LVL2_LAT: 101
> P_LVL3_LAT: 1001
>
> Is there no way to tell my BIOS to unblock those states ? I mean, are they blocked for stability
> purposes (in what case I assume this is a workaround for a bug in the chipset/CPU/whatever), or are
> they just not enabled for an obscure reason ?
Wellcome to the large family of owners of boards/computers with broken ACPI
BIOSes (or hardware bugs ???)...
I didn't find any way how to unblock them. Nobody but BIOS authors know, why
they are blocked, but it seems to be a common practice of current ACPI BIOS
writers :-(.
I have the same problem with ALL of my machines, including my notebook
(Clevo D610SU). None of them supports native Linux ACPI because of this.
On Athlon boards, I'm successfully using athcool
( http://members.jcom.home.ne.jp/jacobi/linux/files/athcool-0.3.11.tar.gz ),
it substantially decreases CPU temperature even with C1 due to enabling
"HALT Command detection" bit on the NB. On some systems, I've patched kernel
to use C2 and C3, which, together with athcool, seems to have even better
effect:
root@co:/home/tv/il2sturmovikfb# cat /proc/acpi/processor/CPU1/power
active state: C2
max_cstate: C8
bus master activity: 000007ff
states:
C1: type[C1] promotion[C2] demotion[--] latency[000] usage[17803710] duration[00000000000000000000]
*C2: type[C2] promotion[--] demotion[C1] latency[101] usage[116616196] duration[00000000277739332216]
You can see 101 in latency field, which is normally prohibited :-)
C3 is not used because of lack of bus mastering capability
(it's on another of my boards, MSI KT6 Delta).
HOWEVER, as many ACPI people already said several times, IT MAY BE RISKY AND
you CAN severely DAMAGE YOUR DATA when experimenting with this. So it's just
on you, how do you decide.
With regards, Pavel Troller
next prev parent reply other threads:[~2006-02-05 15:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-05 14:21 Question about AthlonXP on nforce 2 : C2-C3 states Arthur Huillet
2006-02-05 14:37 ` Pavel Troller
2006-02-05 15:07 ` Arthur Huillet
2006-02-05 15:42 ` Pavel Troller [this message]
2006-02-05 15:55 ` Arthur Huillet
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=20060205154245.GA31112@tangens.sinus.cz \
--to=patrol@sinus.cz \
--cc=arthur.huillet@agoctrl.org \
--cc=linux-acpi@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox