linux-kernel - Re: acpi_idle: Very idle Core i7 machine never enters C3

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]

Date:	Tue, 25 May 2010 19:55:07 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Len Brown <lenb@...nel.org>
Cc:	"Yu, Luming" <luming.yu@...el.com>,
	Philip Langdale <philipl@...rt.org>,
	Jeff Garrett <jeff@...rrett.org>,
	Andi Kleen <andi@...stfloor.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: acpi_idle: Very idle Core i7 machine never enters C3

On Tue, May 25, 2010 at 11:33:39AM -0400, Len Brown wrote:

> So if we see a nehalem system that has BM_STS *always* set,
> even when no devices are active in the system, my guess is
> that the BIOS mis-configured the chip-set and we should
> ignore that bit.  If BM_STS is changing at run time, then
> that is a more interesting situation, and we should endeavor
> to find what device activity is changing it.

Right. Determining that seems... awkward. FWIW, we've been shipping 
Luming's patch for several months now without anything obviously 
breaking in the process. This behaviour seems reasonably prevelant on 
Nehalem-EX systems.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/