linux-kernel - Re: [PATCH] ACPI: make acpi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C48B730.30708@gmail.com>
Date:	Thu, 22 Jul 2010 22:25:04 +0100
From:	Iain <selsinork@...il.com>
To:	Len Brown <lenb@...nel.org>
CC:	Andi Kleen <andi@...stfloor.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"Yu, Luming" <luming.yu@...el.com>,
	Philip Langdale <philipl@...rt.org>,
	Jeff Garrett <jeff@...rrett.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"venki@...gle.com" <venki@...gle.com>
Subject: Re: [PATCH] ACPI: make acpi_idle Nehalem-aware

Len Brown wrote:
> However, we'll still have issues with systems
> like the HP DL360 G6 which explicity set the
> flag to ask for BM_STS checking and configure
> the chipset such that BM_STS is active.
> That may require a BIOS fix, or we may
> have to run intel_idle on that box --
> since intel_idle ignores BM_STS always
> and instead relies on drivers to use pm_qos
> to register device latency constraints.

I'm curious as to why you see a problem with the DL380G6 as the one I have here happily sits in C6 when idle.

your turbostat util shows:

  CPU  GHz  TSC   %c0    %c1    %c3    %c6   %pc3   %pc6
  avg 1.64 2.27   0.16   0.12   0.00  99.71   0.00  90.15

and powertop has results like:

Cn                Avg residency       P-states (frequencies)
C0 (cpu running)        ( 0,1%)       Turbo Mode     0,0%
polling           0,0ms ( 0,0%)         2,27 Ghz     0,0%
C1 mwait          0,1ms ( 0,0%)         2,13 Ghz     0,0%
C2 mwait          1,0ms ( 0,0%)         2,00 Ghz     0,0%
C3 mwait         90,4ms (99,9%)         1,60 Ghz   100,0%

this is with v2.6.35-rc5-176-gcd5b8f8 and using acpi_idle. I've deliberately disabled intel_idle to test, however using intel_idle 
gives almost identical results.

Looking at the bug 15886, the Access Size 0x03 entries you mentioned are all 0x01 on this system. I've also uploaded the acpidump 
from this DL380G6 to that bug so that you can check I've not just looked in the wrong place.

Did the first acpidump come from a system with the 'HP Power Regulator' setting in the bios set to OS Control mode ?  My system is 
set this way and it seems to work as expected.
The other settings for this option appear to be designed to override OS power management controls, for example the description of 
the 'Static High Performance' option suggests it'll somehow force the CPU to operate in the highest performance mode all of the 
time: "HP Static High Performance Mode: Processors will run in their maximum power/performance state at all times regardless of the 
OS power management policy".

If this does turn out to be as simple as a bios setting, should we really be trying to workaround what may be a legitimate decision 
by the servers admin ?

Iain
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/