[Top] [All Lists]

Re: Handling system reset

To: Keith Owens <kaos@xxxxxxx>
Subject: Re: Handling system reset
From: Todd Inglett <tinglett@xxxxxxxxxxxx>
Date: 26 Nov 2002 11:06:18 -0600
Cc: kdb@xxxxxxxxxxx
In-reply-to: <16040.1038270360@xxxxxxxxxxxxxxxxxxxxxx>
References: <16040.1038270360@xxxxxxxxxxxxxxxxxxxxxx>
Sender: kdb-bounce@xxxxxxxxxxx
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

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.


<Prev in Thread] Current Thread [Next in Thread>