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

[Bruce Evans]

On Wed, 15 Dec 2004, Kris Kennaway wrote:

> On Tue, Dec 14, 2004 at 09:48:48PM -0500, John Baldwin wrote:
> > On Tuesday 14 December 2004 07:10 pm, Kris Kennaway wrote:
> > > 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.
>
> This is already set, and it doesn't always fix the problem.

debug.kdb.stop_cpus=0 should be expected to increase problems.  Given time,
the other CPU are quite likely to enter ddb for whatever reason the first
one did.  Then they stomp on ddb's global state (starting with ddb_regs).

The NMI would need locking to prevent the CPUs stopping each other.

> I often
> get overlapping panics from the other CPUs on this machine, and it
> often locks up when trying to enter DDB, or while printing the panic
> string (the other day it only got as far as 'p' before hanging).

panic() needs much the same locking as ddb to prevent concurrent entry.
It must be fairly likely for all CPUs to panic on the same asertion.
This is like all CPUs entering ddb on the same breakpoint.

Bruce