[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080904212245.GQ3400@redhat.com>
Date: Thu, 4 Sep 2008 17:22:45 -0400
From: Don Zickus <dzickus@...hat.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: "Mingarelli, Thomas" <Thomas.Mingarelli@...com>,
Vivek Goyal <vgoyal@...hat.com>, Ingo Molnar <mingo@...e.hu>,
Prarit Bhargava <prarit@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"arozansk@...hat.com" <arozansk@...hat.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
"Maciej W. Rozycki" <macro@...ux-mips.org>
Subject: Re: [PATCH RFC] NMI Re-introduce un[set]_nmi_callback
On Thu, Sep 04, 2008 at 10:53:45PM +0200, Andi Kleen wrote:
> So if your handler can decide "This is an NMI that came from
> a source i know about" it can be a proper[1] NMI cititzen.
The way it was explained to me months ago, is that it can't. Currently it
works by making sure the nmi watchdog is disabled on the box (either
compiled off, or nmi_watchdog=0). Then it registers itself on the DIE
chain. Because it is on the top of the chain, it just so happens to
be the first handler to process the NMIs, so HP is happy. Kdump works
because it registers later on top of the HP handler thus it is called
before HP can panic the box. However, I suspect if one were to run
oprofile in nmi mode, HP would panic the box on the first profile point.
>
> Otherwise it will be hard to make it coexist nicely.
Hence our attempt at a solution by creating a registration for a new
nmi_handler, which in hindsight seemed to miss a couple of cases.
Cheers,
Don
--
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