From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Len Brown <lenb@kernel.org>
Cc: "Yu, Luming" <luming.yu@intel.com>,
Philip Langdale <philipl@overt.org>,
Jeff Garrett <jeff@jgarrett.org>,
Andi Kleen <andi@firstfloor.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"venki@google.com" <venki@google.com>
Subject: Re: acpi_idle: Very idle Core i7 machine never enters C3
Date: Tue, 25 May 2010 19:55:07 +0100 [thread overview]
Message-ID: <20100525185507.GA15997@srcf.ucam.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1005251114420.4114@localhost.localdomain>
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
next prev parent reply other threads:[~2010-05-25 18:55 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-26 8:47 acpi_idle: Very idle Core i7 machine never enters C3 Jeff Garrett
2010-01-26 12:41 ` peng huang
2010-01-26 14:59 ` Jeff Garrett
2010-01-27 13:27 ` peng huang
2010-02-05 16:22 ` Jeff Garrett
2010-01-26 21:45 ` Andi Kleen
2010-02-05 16:09 ` Jeff Garrett
2010-02-05 17:45 ` Len Brown
2010-02-05 20:53 ` Jeff Garrett
2010-04-27 2:40 ` Philip Langdale
2010-04-27 7:26 ` Len Brown
2010-04-27 15:41 ` Philip Langdale
2010-04-27 12:47 ` Jeff Garrett
2010-04-30 14:57 ` Philip Langdale
2010-04-30 16:25 ` Len Brown
2010-04-30 17:44 ` Matthew Garrett
2010-04-30 18:35 ` Philip Langdale
2010-05-25 5:43 ` Len Brown
2010-05-25 5:59 ` Yu, Luming
2010-05-25 12:39 ` Matthew Garrett
2010-05-25 12:43 ` Matthew Garrett
2010-05-25 15:33 ` Len Brown
2010-05-25 18:55 ` Matthew Garrett [this message]
2010-07-21 21:31 ` [PATCH] ACPI: make acpi_idle Nehalem-aware Len Brown
2010-07-22 0:53 ` Venkatesh Pallipadi
2010-07-22 7:47 ` Andi Kleen
2010-07-22 15:57 ` Len Brown
2010-07-22 21:21 ` [PATCH] ACPI: skip checking BM_STS if the BIOS doesn't ask for it Len Brown
2010-07-22 21:40 ` [PATCH] ACPI: create "processor.bm_check_disable" boot param Len Brown
2010-07-26 7:24 ` Andi Kleen
2010-07-27 0:19 ` Len Brown
2010-07-27 11:28 ` Andi Kleen
2010-07-28 18:58 ` Len Brown
2010-07-22 21:25 ` [PATCH] ACPI: make acpi_idle Nehalem-aware Iain
2010-07-22 21:53 ` Iain
2010-07-22 22:01 ` Len Brown
2010-07-23 12:40 ` Iain
2010-08-03 6:55 ` Pavel Machek
2010-08-03 7:05 ` Andi Kleen
2010-05-25 12:37 ` acpi_idle: Very idle Core i7 machine never enters C3 Matthew Garrett
2010-05-25 15:40 ` Len Brown
2010-07-22 5:34 ` Len Brown
2010-02-01 14:10 ` Pavel Machek
2010-02-05 16:30 ` Jeff Garrett
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=20100525185507.GA15997@srcf.ucam.org \
--to=mjg59@srcf.ucam.org \
--cc=andi@firstfloor.org \
--cc=jeff@jgarrett.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luming.yu@intel.com \
--cc=philipl@overt.org \
--cc=venki@google.com \
/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;
as well as URLs for NNTP newsgroup(s).