From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3 Date: Tue, 25 May 2010 19:55:07 +0100 Message-ID: <20100525185507.GA15997@srcf.ucam.org> References: <20100426194002.586fbaa5@fido5> <20100427124703.GA16706@jgarrett.org> <20100430174447.GA14889@srcf.ucam.org> <20100525124325.GC7876@srcf.ucam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from cavan.codon.org.uk ([93.93.128.6]:49286 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756378Ab0EYSzZ (ORCPT ); Tue, 25 May 2010 14:55:25 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Len Brown Cc: "Yu, Luming" , Philip Langdale , Jeff Garrett , Andi Kleen , Linux Kernel Mailing List , "linux-acpi@vger.kernel.org" , "venki@google.com" 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@srcf.ucam.org