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

[Maciej Rutecki <maciej.rutecki@gmail.com>]

I created a Bugzilla entry at 
https://bugzilla.kernel.org/show_bug.cgi?id=33252
for your bug report, please add your address to the CC list in there, thanks!

On czwartek, 7 kwietnia 2011 o 00:30:36 Shaun Ruffell wrote:
> 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@redhat.com>
> 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@redhat.com>
>     Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
>     Cc: Lin Ming <ming.m.lin@intel.com>
>     LKML-Reference: <4D8BAB49.3080701@openvz.org>
>     Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Maciej Rutecki
http://www.maciek.unixy.pl