lkml.org 
[lkml]   [2011]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [regression 2.6.39-rc2][bisected] "perf, x86: P4 PMU - Read proper MSR register to catch" and NMIs
Date
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


\
 
 \ /
  Last update: 2011-04-13 21:37    [W:0.079 / U:49.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site