cvs commit: src/sys/i386/i386 vm_machdep.c

[John Baldwin]

On Tuesday 14 December 2004 07:10 pm, Kris Kennaway wrote:
> On Tue, Dec 14, 2004 at 02:55:00PM -0800, Nate Lawson wrote:
> > >Erm, well, that's not always easy since sometimes when you panic you
> > > can't talk to the other CPUs for whatever reason.  Putting back the
> > > proxy reset doesn't hurt for now but does restore functionality in at
> > > least some cases.  I'd rather have that then certain hard panics not
> > > get into ddb because we couldn't get onto the BSP to run ddb.
> >
> > Perhaps you could give me some pointers on what is counted on to be
> > working when panic() is called?  I can't come up with a situation where
> > the proxy code couldn't be used upon entry to ddb.  If there were any
> > cases like this, the proxy code wouldn't work for cpu_reset() either.
> > Also, in such a case, it's hard to see how ddb could be usable since it
> > tries to stop other processors, which requires similar code to the proxy.
> >
> > Or in other words, if you have enough capability to call panic() or
> > break to ddb, then you have enough resources to do an IPI and get onto
> > the BSP.
>
> NB: DDB often isn't usable on SMP machines thesedays, and will hang
> when a panic tries to enter it.

Try debug.kdb.stop_cpus=0 (sysctl and tunable) to prevent KDB from trying to 
stop the other CPUs.  Another possible fix that ups@ has talked about is 
changing IPI_STOP to use an NMI rather than a vector (you can send NMI IPIs 
via the local APIC) so that IPI_STOP is more reliable.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org