lkml.org 
[lkml]   [2011]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2011-03-21 18:11    [W:0.064 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site