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 03:37:40PM -0400, Don Zickus wrote:
    > On Mon, Mar 21, 2011 at 01:22:35PM -0500, Jack Steiner wrote:
    > > On Mon, Mar 21, 2011 at 01:51:10PM -0400, Don Zickus wrote:
    > > > On Mon, Mar 21, 2011 at 07:26:51PM +0300, Cyrill Gorcunov wrote:
    > > > > On 03/21/2011 07:14 PM, Ingo Molnar wrote:
    > > > > >
    > > > > > * Jack Steiner <steiner@sgi.com> wrote:
    > > > > >
    > > > > >> This fixes a problem seen on UV systems handling NMIs from the node controller.
    > > > > >> The original code used the DIE notifier as the hook to get to the UV NMI
    > > > > >> handler. This does not work if performance counters are active - the hw_perf
    > > > > >> code consumes the NMI and the UV handler is not called.
    > > >
    > > > Well that is a bug in the perf code. We have been dealing with 'perf'
    > > > swallowing NMIs for a couple of releases now. I think we got rid of most
    > > > of the cases (p4 and acme's core2 quad are the only cases I know that are
    > > > still an issue).
    > > >
    > > > I would much prefer to investigate the reason why this is happening
    > > > because the perf nmi handler is supposed to check the global interrupt bit
    > > > to determine if the perf counters caused the nmi or not otherwise fall
    > > > through to other handler like SGI's nmi button in this case.
    > >
    > > The patch that I posted is based on a RHEL6.1 patch that I'm running internally.
    > > Unless something has very recently changed in the RH sources, the perf
    > > NMI handler unconditionally returns NOTIFY_STOP if it handles an NMI.
    > > If no NMI was handled, it returns NOTIFY_DONE. This sometimes works
    > > and allows the platform generated NMI to be processed but if both NMI
    > > sources trigger at about he same time, the lower priority event
    > > will be lost.
    >
    > Not necessarily, if both are triggered, you should still get _two_ NMIs.
    > It may get processed in the wrong order but it should still get correctly
    > processed.


    Let me do some more testing with the UV NMI priority set higher than the hw_perf
    priority. When I tried this earlier, I thought I saw problems but I'm
    not certain that it was not caused by a different error.


    >
    > >
    > > The root cause of the problem is that architecturally, x86 does not
    > > have a way to identifies the source(s) that cause an NMI. If multiple
    > > events occur at about the same time, there is no way that I can see that the
    > > OS can detect it.
    >
    > There are registers we can check to see who owns trigger the NMI (at least
    > for the perf code, the SGI code maybe not, which is why I set it to a
    > lower priority to be a catch-all).
    >
    > I'm not aware of the x86 architecture dropping NMIs, so they should all
    > get processed. It is just a matter of which subsystems get determine if
    > they are the source of the NMI or not.
    >
    > >
    > > >
    > > > My first impression is the skip nmi logic in the perf handler is probably
    > > > accidentally thinking the SGI external nmi is the perf's 'extra' nmi it is
    > > > supposed to skip and thus swallows it. At least that is the impression I
    > >
    > > Agree
    > >
    > >
    > > > get from the RedHat bugzilla which says SGI is running 'perf top', getting
    > > > a hang, then pressing their nmi button to see the stack traces.
    > > >
    > > > Jack,
    > > >
    > > > I worked through a number of these issues upstream and I already talked to
    > > > George and Russ over here at RedHat about working through the issue over
    > > > here with them. They can help me get access to your box to help debug.
    > >
    > > Russ is right down the hall.
    >
    > Great!
    >
    > Cheers,
    > Don


    \
     
     \ /
      Last update: 2011-03-21 21:41    [W:0.057 / U:61.292 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site