[regression 2.6.39-rc2][bisected] "perf, x86: P4 PMU - Read properMSR register to catch" and NMIs

[Shaun Ruffell]

Hello Don,

With 2.6.39-rc2 I was seeing the following NMIs when building the kernel:

[  191.647131] Uhhuh. NMI received for unknown reason 21 on CPU 3.
[  191.650068] Do you have a strange power saving mode enabled?
[  191.650068] Dazed and confused, but trying to continue
[  676.020001] Uhhuh. NMI received for unknown reason 21 on CPU 1.
[  676.020001] Do you have a strange power saving mode enabled?
[  676.020001] Dazed and confused, but trying to continue
[  892.520335] Starting new kernel

I'm running on a Dell PowerEdge 2600 with the following processor:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Xeon(TM) CPU 3.06GHz
stepping        : 7
...

I was able to bisect it down to commit 242214f9c1eeaae40, but I'm not
certain where to go from here.  Is this something that is already known
or is there more information I should try to collect? 

Here is the commit for reference:

commit 242214f9c1eeaae40eca11e3b4d37bfce960a7cd
Author: Don Zickus <dzickus@xxxxxxxxxx>
Date:   Thu Mar 24 23:36:25 2011 +0300

    perf, x86: P4 PMU - Read proper MSR register to catch unflagged overflows
    
    The read of a proper MSR register was missed and instead of
    counter the configration register was tested (it has
    ARCH_P4_UNFLAGGED_BIT always cleared) leading to unknown NMI
    hitting the system. As result the user may obtain "Dazed and
    confused, but trying to continue" message. Fix it by reading a
    proper MSR register.
    
    When an NMI happens on a P4, the perf nmi handler checks the
    configuration register to see if the overflow bit is set or not
    before taking appropriate action.  Unfortunately, various P4
    machines had a broken overflow bit, so a backup mechanism was
    implemented.  This mechanism checked to see if the counter
    rolled over or not.
    
    A previous commit that implemented this backup mechanism was
    broken. Instead of reading the counter register, it used the
    configuration register to determine if the counter rolled over
    or not. Reading that bit would give incorrect results.
    
    This would lead to 'Dazed and confused' messages for the end
    user when using the perf tool (or if the nmi watchdog is
    running).
    
    The fix is to read the counter register before determining if
    the counter rolled over or not.
    
    Signed-off-by: Don Zickus <dzickus@xxxxxxxxxx>
    Signed-off-by: Cyrill Gorcunov <gorcunov@xxxxxxxxxx>
    Cc: Lin Ming <ming.m.lin@xxxxxxxxx>
    LKML-Reference: <4D8BAB49.3080701@xxxxxxxxxx>
    Signed-off-by: Ingo Molnar <mingo@xxxxxxx>

diff --git a/arch/x86/kernel/cpu/perf_event_p4.c b/arch/x86/kernel/cpu/perf_event_p4.c
index 3769ac8..d3d7b59 100644
--- a/arch/x86/kernel/cpu/perf_event_p4.c
+++ b/arch/x86/kernel/cpu/perf_event_p4.c
@@ -777,6 +777,7 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_perf_event *hwc)
 	 * the counter has reached zero value and continued counting before
 	 * real NMI signal was received:
 	 */
+	rdmsrl(hwc->event_base, v);
 	if (!(v & ARCH_P4_UNFLAGGED_BIT))
 		return 1;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/