Handling system reset

[Todd Inglett]

On Mon, 2002-11-25 at 18:26, Keith Owens wrote:

> The problem with a broadcast NMI is that all processors end up in the
> NMI state.  I don't know about ppc, but on x86 and ia64, the processors
> will not take another NMI until they exit from the first one.  IOW, the
> broadcast NMI stops the kdb NMI from doing anything.  The only solution
> is to use KDB_ENTER() on the first cpu that gets the NMI and to drop
> back to normal code for all the other cpus.  Code something like this

This is pretty much what I am doing.  However, our processors are not in
a "reset state" so we *can* take a reset while handling a reset.  We
aren't using reset as a kdb NMI anyway since it can't be pulled by
software.

I would prefer that if a processor enters kdb on a reset and it detects
it is already in kdb that it would simply return.  Then if my system
drops into kdb through some other means (perhaps a panic) and the IPI
fails to stop other processors, I could simply hit the reset button to
nab those other processors -- without screwing up the state of the
processors already in kdb.

The only trouble with this thought is that I would not be able to use
reset to "recover" if kdb itself has problems.  Oh well.

-todd