[lkml]   [2002]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: NMI handling rework

    -- Snipped from the patch --

    If the handler actually handles the NMI, it should return NOTIFY_OK.
    If it did not handle the NMI, it should return NOTIFY_DONE. It may "or"
    on NOTIFY_STOP_MASK to the return value if it does not want other
    handlers after it to be notified.

    -- End snip --

    > It is still possible, though unlikely, that two NMI sources could occur
    > at the same time. Maybe that's not worth worrying about, and maybe for
    > the APICs it works fine.

    Am I reading this correctly? As long as no one passes back NOTIFY_STOP_MASK,
    all handlers are run. Assuming that all external NMI sources have a means of
    checking whether they were the source, this would work like shared PCI

    > Not on the i386 family. Once an NMI is accepted by the CPU, it gets
    > internally masked until an iret instruction gets executed. If another NMI
    > happens maenwhile, it's latched by the processor internally and dispatched
    > as soon as NMIs are unmasked. Further NMIs received when masked are lost.

    So... We're running through the handler list servicing an NMI, two more NMIs
    come in and we latch one (the other is dropped). It doesn't matter. Either
    affected handlers have not run yet and will get run on the current pass, or
    they will run on the next pass. You may have two handlers run on a single
    but you should not drop any. True??

    This assumes i386 architecture and all handlers are run. I don't know about
    other archs.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.027 / U:1.980 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site