From: Carsten Emde <C.Emde@osadl.org>
To: Len Brown <lenb@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
"H. Peter Anvin" <hpa@linux.intel.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Asit Mallick <asit.k.mallick@intel.com>, Greg KH <gregkh@suse.de>,
Mike Galbraith <efault@gmx.de>,
Thomas Gleixner <tglx@linutronix.de>,
Alexander Holler <holler@ahsoftware.de>
Subject: Re: Intel i7/X 980 freezes with CONFIG_INTEL_IDLE and frequency scaling
Date: Mon, 04 Apr 2011 16:19:58 +0200 [thread overview]
Message-ID: <4D99D38E.9040700@osadl.org> (raw)
In-Reply-To: <4D96D147.60607@osadl.org>
On 04/02/2011 09:33 AM, Carsten Emde wrote:
> after upgrading a Fedora 14 based Intel i7/X 980 box to 2.6.39-rc1, the
> system freezes when frequency scaling is started. Looks like a complete
> CPU halt, since neither SysRq nor anything else can convince the box to
> provide any information.
> Loading acpi_cpufreq is save, but selecting the performance
> scaling_governor immediately freezes the system. Selecting the ondemand
> scaling_governor freezes the system when load is generated for the first
> time, presumably when the frequency is increased. Fortunately, when the
> kernel was built with another config file, the system did not freeze.
> After enabling and disabling some suspicious config items (before going
> through the hassle and bisect the config using ktest.pl), the culprit
> was found to be CONFIG_INTEL_IDLE. Fedora 14 enables it.
While digging deeper into this mystery, I found a detail that may
connect this problem to the poweroff problem
(https://lkml.org/lkml/2011/3/31/458).
The CPU (i7/X 980 box) apparently freezes when it executes
__monitor(¤t_thread_info()->flags, 0, 0);
which is
static inline void __monitor(const void *eax, unsigned long ecx,
unsigned long edx)
{
/* "monitor %eax, %ecx, %edx;" */
asm volatile(".byte 0x0f, 0x01, 0xc8;"
:: "a" (eax), "c" (ecx), "d"(edx));
}
After removing this line from the execution path (see below patch), the
problem is gone and the system no longer freezes when processor
frequency scaling is enabled. I double-checked this, so I am pretty sure
that this is, in fact, the case.
Interestingly, the __monitor() command is also used in mwait_play_dead()
at arch/x86/kernel/smpboot.c where the poweroff problem is originating.
Maybe, a misbehavior of this instruction also causes the poweroff problem.
But we should solve this problem first. Len or anybody else at Intel, I
don't think that I can go any further without your help. Do you have any
explanation what is going on here when the processor
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz
stepping : 2
encounters the above instruction?
Thanks,
-Carsten.
Index: linux-2.6.39-rc1/drivers/idle/intel_idle.c
===================================================================
--- linux-2.6.39-rc1.orig/drivers/idle/intel_idle.c
+++ linux-2.6.39-rc1/drivers/idle/intel_idle.c
@@ -99,11 +99,54 @@ static unsigned long long auto_demotion_
*/
#define CPUIDLE_FLAG_TLB_FLUSHED 0x10000
+static int intel_idle_monitor(struct cpuidle_device *dev,
+ struct cpuidle_state *state, int monitor);
+
+static int intel_idle_westmere(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ return intel_idle_monitor(dev, state, 0);
+}
+
+static int intel_idle(struct cpuidle_device *dev,
+ struct cpuidle_state *state)
+{
+ return intel_idle_monitor(dev, state, 1);
+}
+
/*
* States are indexed by the cstate number,
* which is also the index into the MWAIT hint array.
* Thus C0 is a dummy.
*/
+static struct cpuidle_state westmere_cstates[MWAIT_MAX_NUM_CSTATES] = {
+ { /* MWAIT C0 */ },
+ { /* MWAIT C1 */
+ .name = "C1-NHM",
+ .desc = "MWAIT 0x00",
+ .driver_data = (void *) 0x00,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 3,
+ .target_residency = 6,
+ .enter = &intel_idle_westmere },
+ { /* MWAIT C2 */
+ .name = "C3-NHM",
+ .desc = "MWAIT 0x10",
+ .driver_data = (void *) 0x10,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 20,
+ .target_residency = 80,
+ .enter = &intel_idle_westmere },
+ { /* MWAIT C3 */
+ .name = "C6-NHM",
+ .desc = "MWAIT 0x20",
+ .driver_data = (void *) 0x20,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_TLB_FLUSHED,
+ .exit_latency = 200,
+ .target_residency = 800,
+ .enter = &intel_idle_westmere },
+};
+
static struct cpuidle_state nehalem_cstates[MWAIT_MAX_NUM_CSTATES] = {
{ /* MWAIT C0 */ },
{ /* MWAIT C1 */
@@ -212,7 +255,8 @@ static struct cpuidle_state atom_cstates
* @state: cpuidle state
*
*/
-static int intel_idle(struct cpuidle_device *dev, struct cpuidle_state
*state)
+static int intel_idle_monitor(struct cpuidle_device *dev,
+ struct cpuidle_state *state, int monitor)
{
unsigned long ecx = 1; /* break on interrupt flag */
unsigned long eax = (unsigned long)cpuidle_get_statedata(state);
@@ -239,8 +283,8 @@ static int intel_idle(struct cpuidle_dev
stop_critical_timings();
if (!need_resched()) {
-
- __monitor((void *)¤t_thread_info()->flags, 0, 0);
+ if (monitor)
+ __monitor((void *)¤t_thread_info()->flags, 0, 0);
smp_mb();
if (!need_resched())
__mwait(eax, ecx);
@@ -338,12 +382,17 @@ static int intel_idle_probe(void)
case 0x2E: /* Nehalem-EX Xeon */
case 0x2F: /* Westmere-EX Xeon */
case 0x25: /* Westmere */
- case 0x2C: /* Westmere */
cpuidle_state_table = nehalem_cstates;
auto_demotion_disable_flags =
(NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_DEMOTE);
break;
+ case 0x2C: /* Special Westmere? */
+ cpuidle_state_table = westmere_cstates;
+ auto_demotion_disable_flags =
+ (NHM_C1_AUTO_DEMOTE | NHM_C3_AUTO_DEMOTE);
+ break;
+
case 0x1C: /* 28 - Atom Processor */
cpuidle_state_table = atom_cstates;
break;
prev parent reply other threads:[~2011-04-04 14:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 20:41 Linux 2.6.33.8 Greg KH
2011-03-21 20:41 ` Greg KH
2011-03-31 18:22 ` Carsten Emde
2011-04-01 4:35 ` Mike Galbraith
2011-04-02 9:14 ` Carsten Emde
2011-04-02 10:24 ` Alexander Holler
2011-04-02 11:27 ` Carsten Emde
2011-04-04 9:20 ` Alexander Holler
2011-04-02 21:08 ` Carsten Emde
2011-04-02 22:23 ` Thomas Gleixner
2011-04-02 7:33 ` Intel i7/X 980 freezes with CONFIG_INTEL_IDLE and frequency scaling Carsten Emde
2011-04-04 14:19 ` Carsten Emde [this message]
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=4D99D38E.9040700@osadl.org \
--to=c.emde@osadl.org \
--cc=arjan@linux.intel.com \
--cc=asit.k.mallick@intel.com \
--cc=efault@gmx.de \
--cc=gregkh@suse.de \
--cc=holler@ahsoftware.de \
--cc=hpa@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.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