[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110321170832.GC12718@sgi.com>
Date: Mon, 21 Mar 2011 12:08:32 -0500
From: Jack Steiner <steiner@....com>
To: Cyrill Gorcunov <gorcunov@...il.com>
Cc: Ingo Molnar <mingo@...e.hu>, Don Zickus <dzickus@...hat.com>,
tglx@...utronix.de, hpa@...or.com, x86@...nel.org,
linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] x86, UV: Fix NMI handler for UV platforms
On Mon, Mar 21, 2011 at 08:00:53PM +0300, Cyrill Gorcunov wrote:
> On 03/21/2011 07:43 PM, Cyrill Gorcunov wrote:
> ...
> >
> > I think Jack might need to setup priority for his notifier, like
> >
> > static struct notifier_block uv_dump_stack_nmi_nb = {
> > .notifier_call = uv_handle_nmi,
> > .priority = NMI_LOCAL_HIGH_PRIOR+1,
> > };
> >
> > so it would be called before perf nmi. Don, am I right?
> >
> > Since for perf nmis we do have
> >
> > static __read_mostly struct notifier_block perf_event_nmi_notifier = {
> > .notifier_call = perf_event_nmi_handler,
> > .next = NULL,
> > .priority = NMI_LOCAL_LOW_PRIOR,
> > };
> >
>
> I must admit I've missed the fact that Jack has tried NMIs priorities, right?
> x86_platform_ops seems to be a cleaner indeed (btw I think p4 pmu kgdb issue
> is exactly the same problem) but same time this might end up in over-swelled
> ideas behind this small code snippet. Dunno. Probably we need some per-cpu
> system status for nmi reasons other than unknown nmis...
We use KDB internally, and yes, it has the same issue. The version of the
patch that uses KDB OR's the "handled" status for both KDB & the UV NMI handler.
If either KDB or the UV NMI handler returns "handled", the code in traps.c exits
after the call to the first die notifier.
Not particularily pretty but I could not find a better way to do it.
--- jack
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists