All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@openvz.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Lin Ming <ming.m.lin@intel.com>, Don Zickus <dzickus@redhat.com>,
	Shaun Ruffell <sruffell@digium.com>,
	Maciej Rutecki <maciej.rutecki@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Stephane Eranian <eranian@google.com>,
	Robert Richter <robert.richter@amd.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH -tip] perf, x86: fix unknown NMIs on a Pentium4 box
Date: Thu, 14 Apr 2011 18:48:48 +0400	[thread overview]
Message-ID: <4DA70950.3060102@openvz.org> (raw)

From: Don Zickus <dzickus@redhat.com>
Subject: [PATCH -tip] perf, x86: fix unknown NMIs on a Pentium4 box

When using perf on a Pentium4 box, lots of unknown NMIs would be generated.
This is the result of a P4 quirk that is subtle.  The P4 generates an NMI
when the counter overflow and unlike other arches where the NMI is a one time
event, the P4 continues to assert its NMI until clear by the OS.

As a side effect to this quirk, the NMI on the apic is masked off to prevent
a stream of NMIs until the overflow flag is cleared.  During the perf
re-design, this subtle-ness was overlooked and the apic was unmasked _before_
the overflow flag was cleared.  As a result, this generated an extra NMI on
the P4 mchines.

The fix is trivial, wait until the NMI is properly handled before un-masking
the apic.

Sadly, in the old nmi watchdog there was a note that explained this exact
behaviour.

 Cyrill Gorcunov: Added a comment into code itself. We should consider
if we need to unmask LVTPC if no oveflow happened at all.

 Ingo Molnar: Pointed out that unmasking unconditionally is proven by time
to be correct.

Signed-off-by: Don Zickus <dzickus@redhat.com>
Tested-by: Shaun Ruffell <sruffell@digium.com>
Tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
CC: Lin Ming <ming.m.lin@intel.com>
CC: Maciej Rutecki <maciej.rutecki@gmail.com>
CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
CC: Stephane Eranian <eranian@google.com>
CC: Robert Richter <robert.richter@amd.com>
---

Ingo, please make sure I've added conform notes about conditional/uconditional
unmasking in changelog. Don, I've added a comment in code just to not forget why
we need it. Thanks.

 arch/x86/kernel/cpu/perf_event.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Index: linux-2.6.git/arch/x86/kernel/cpu/perf_event.c
=====================================================================
--- linux-2.6.git.orig/arch/x86/kernel/cpu/perf_event.c
+++ linux-2.6.git/arch/x86/kernel/cpu/perf_event.c
@@ -1370,9 +1370,16 @@ perf_event_nmi_handler(struct notifier_b
 		return NOTIFY_DONE;
 	}

-	apic_write(APIC_LVTPC, APIC_DM_NMI);

 	handled = x86_pmu.handle_irq(args->regs);
+
+	/*
+	 * Note the unmasking of LVTPC entry must be
+	 * done *after* counter oveflow flag is cleared
+	 * otherwise it might lead to double NMIs generation.
+	 */
+	apic_write(APIC_LVTPC, APIC_DM_NMI);
+
 	if (!handled)
 		return NOTIFY_DONE;


-- 
    Cyrill

             reply	other threads:[~2011-04-14 14:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-14 14:48 Cyrill Gorcunov [this message]
2011-04-14 15:03 ` [PATCH -tip] perf, x86: fix unknown NMIs on a Pentium4 box Ingo Molnar
2011-04-14 15:06   ` Cyrill Gorcunov
2011-04-14 17:43 ` Ingo Molnar
2011-04-14 17:44   ` Ingo Molnar
2011-04-14 17:49     ` Cyrill Gorcunov
2011-04-14 18:12       ` Shaun Ruffell
2011-04-14 18:14         ` Cyrill Gorcunov
2011-04-14 18:19         ` Cyrill Gorcunov
2011-04-14 19:35           ` David Ahern
2011-04-14 17:46   ` Cyrill Gorcunov
2011-04-14 18:32   ` Don Zickus
2011-04-14 18:45     ` Ingo Molnar
2011-04-14 18:46     ` Ingo Molnar
2011-04-14 19:43       ` Cyrill Gorcunov
2011-04-14 19:57         ` Don Zickus
2011-04-14 20:05           ` Cyrill Gorcunov
2011-04-14 20:18             ` Cyrill Gorcunov

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=4DA70950.3060102@openvz.org \
    --to=gorcunov@openvz.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=dzickus@redhat.com \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.rutecki@gmail.com \
    --cc=ming.m.lin@intel.com \
    --cc=mingo@elte.hu \
    --cc=robert.richter@amd.com \
    --cc=sruffell@digium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.