[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110228183759.GD11359@redhat.com>
Date: Mon, 28 Feb 2011 13:37:59 -0500
From: Don Zickus <dzickus@...hat.com>
To: Cyrill Gorcunov <gorcunov@...il.com>
Cc: huang ying <huang.ying.caritas@...il.com>,
"Maciej W. Rozycki" <macro@...ux-mips.org>, x86@...nel.org,
Peter Zijlstra <peterz@...radead.org>,
Robert Richter <robert.richter@....com>, ying.huang@...el.com,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/6] x86, NMI: Allow NMI reason io port (0x61) to be
processed on any CPU
On Sun, Feb 27, 2011 at 02:19:11PM +0300, Cyrill Gorcunov wrote:
> On 02/27/2011 04:01 AM, huang ying wrote:
> ...
> >>
> >> Probably we should put question in another fashion, ie in the fasion of
> >>overall design -- who should be
> >>responsible for handling external nmis, 1) the cpu which apic is configured
> >>to observe such nmis or 2) any cpu?
> >>If we take 1) then no lock is needed and underlied code will report real cpu
> >>number who observed nmi. If
> >>we take 2) then lock is needed but we need a big comment in default_do_nmi
> >>together with probably cpu number
> >>fixed in serr\iochk printk's.
> >
> >I am OK with both solutions.
> >
> >Best Regards,
> >Huang Ying
>
> ok, lets see what others think on this thread
I'm trying to figure out how this affects SGI's systems which currently
enable external NMIs to all cpu's in order to support their nmi button to
dump cpu stacks on a system hang
(arch/x86/kernel/apic/x2apic_uv_x.c::uv_nmi_init)
But feel free to post patches addressing your concerns as I am getting a
little lost in the all the concerns being thrown back and forth.
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