Can't panic from debugger

[Bruce Evans]

On Sun, 23 Dec 2007, Robert Watson wrote:

> On Sun, 23 Dec 2007, Erwin Lansing wrote:
>
>> The amd64 nodes in the pointyhat cluster are starting to behave quite 
>> interestingly.  They stop to respond to ssh, but are still answering ping. 
>> More worrying is that I cannot get a useful dump out of it, as a panic from 
>> the debugger just hangs there, and all I am left with is to pull the plug. 
>> This even happens on a normal working system after entering the debugger, 
>> of which there is a typescript below.
>> ...
> I discovered yesterday that I was seeing the same problem on a dual-cpu, 
> dual-core box in the netperf cluster:

This is as expected.  Debugger context is special, and no non-debugger
functions can be called from it without going through the (unimplemented)
trampoline needed to temporarily leave it.  Some non-debugger functions
may work accidentally or appear to work when called directly.  panic()
is not one of these, since it tends to trip over a lock.  panic()
called from an arbitrary context has the same problem, since the calling
context may hold a lock that is used by panic().  Debugger context
always holds the pseudo-spinlock of masked CPU interrupts and stopped
other CPUs.  panic() (actually boot()) normally begins with a normal
sync() call that is not aware that it may be called in either panic
or debugger context and depends on a large amount of system code working
normally.  It cannot legitimately sync anything when called in debugger
context, since syncing requires i/o and i/o normally requires interrupts.

> I *can* get a coredump if I directly "call doadump" and then "reset", but I 
> can't get one if I just do "panic".

Dumps have some chance of working since they are required to try harder
than sync() to work in any context.  In particular, they are or were
aware that they are not permitted to use interrupts.  Reset has a
better chance of working since it is simpler and reset is a legitimate
debugger command.  I was asleep when the panic debugger command was
added.  Interrupt-driven I/O in sync for panics back then tended to
work bogusly by blowing away both spl*() masks and the hard CPU interrupt
disable mask.

Bruce