On Sat, 17 Jul 2004, Stephen Jones wrote:

> debugger.  So when an MP
> system crashes is it the luck of the draw as to whether you'll get a
> debugger or not?  Does CPU 0
> always get the console?  So when CPU 0 hangs, CPU 1 drops to a debugger
> but you can not
> access it because CPU 0 has the console?

  Whichever CPU enters DDB has the console.  All other CPUs are paused, as
long as they are able to process the pause IPI.  If any other CPU is
looping with interrupts blocked, it will be unable to pause and will
continue to loop.  If a CPU does pause it will save its frame pointer from
the interrupt and access to the register state will be available (to
examine registers or do a traceback).  One exception to this is if the CPU
was waiting for a spinlock;  it will process the pause IPI, but because
it's not entered by an interrupt, it will have not register state for DDB
to access.  The other CPU registers can be accessed by using the "machine
cpu n" command.  If the register state is not available, you will get a
message saying so, or if the CPU has not paused, it will also say so.
The DDB prompt will indicate which CPU's registers are being accessed.

> Then trying to do a dump:
>
> panic: alpha_send_ipi: CPU 1 not running
> panic: alpha_send_ipi: CPU 1 not running
> panic: alpha_send_ipi: CPU 1 not running
> panic: alpha_send_ipi: CPU 1 not running
> panic: alpha_send_ipi: CPU 1 not running

  I saw this the other day as well.  It's a DIAGNOSTIC panic that
indicates a CPU is trying to send an IPI request to another CPU, but that
other CPU is not marked as running.  This would seem to indicate that CPU
1 had been halted, but CPU 0 was still trying to send an IPI request to
it.  I'm not certain how this would happen.

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA