Re: [patch] serial console vs NMI watchdog

[Keith Owens <kaos@ocs.com.au>]

On Mon, 12 Mar 2001 00:27:14 -0800, 
george anzinger <george@mvista.com> wrote:
>Keith Owens wrote:
>> kdb uses NMI IPI to get the other cpu's attention.  One cpu is in
>> control and may or may not be accepting NMI, it depends on the event
>> that entered kdb.  The other cpus end up in kdb code, spinning waiting
>> for a cpu switch.  Initially they are not receiving NMI because they
>> were invoked via NMI which is masked until they exit.
>
>Are you actually twiddling the hardware, or just changing what happens
>on NMI?

No hardware twiddling.  One cpu gets an event which triggers kdb, that
event may or may not be via NMI.  kdb on ix86 then uses NMI to get the
attention of the other cpus, even if they are in a disabled spinloop.
ix86 hardware will not deliver another NMI to a cpu until the cpu
issues iret to return from the NMI handler.

Initially all but one cpu is forced into kdb via the NMI handler so no
more NMI events will occur on those cpus.  The first cpu may or may not
be receiving NMI, it depends on how kdb was invoked on the first cpu.
To do single stepping of code, kdb allows one cpu out of kdb state so
it can execute one instruction at the point it was interrupted.  If the
cpu was entered via NMI then that means exiting from the NMI handler
back to the original code, do single step then back into kdb again.

Having exited the NMI handler, that cpu will start receiving NMI events
again, even though it is still under kdb control.  So some cpus will
get NMI, some will not, depending on user actions.  kdb uses a software
mechanism to selectively disable the NMI watchdog.