From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758927Ab1DNOsz (ORCPT ); Thu, 14 Apr 2011 10:48:55 -0400 Received: from mail-bw0-f46.google.com ([209.85.214.46]:63271 "EHLO mail-bw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758920Ab1DNOsx (ORCPT ); Thu, 14 Apr 2011 10:48:53 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=j/HmYzkuI63tIwmAros39wktLMseKlZhY/dTjMc+y8ku/MEomyno06Z+UXV+M7AxDe i98CC7bxS4/DK50sPFTGbNXQHUcSynqxe2Q78E1j/6wUGNPTaGWl/zYSfa3wOE+VKkME u6wEEZcDQ+q7g92+MyVtU7pXSFFTmdDPZt+Vw= Message-ID: <4DA70950.3060102@openvz.org> Date: Thu, 14 Apr 2011 18:48:48 +0400 From: Cyrill Gorcunov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Ingo Molnar CC: Lin Ming , Don Zickus , Shaun Ruffell , Maciej Rutecki , Peter Zijlstra , Stephane Eranian , Robert Richter , lkml Subject: [PATCH -tip] perf, x86: fix unknown NMIs on a Pentium4 box Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Don Zickus 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 Tested-by: Shaun Ruffell Tested-by: Cyrill Gorcunov Acked-by: Cyrill Gorcunov CC: Lin Ming CC: Maciej Rutecki CC: Peter Zijlstra CC: Stephane Eranian CC: Robert Richter --- 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