Philip Tait wrote:

> We've had a /200 running with Jonathan's update kit (to fix cerror.s and
> dl_open) for a week or so.  Last Friday, the system "halted" with a
> "db>" prompt.  I was able to continue using the "c" command.  Next time
> it happens, what information can I gather to try and trace the problem?

Michael Hitch provided this excellent explanation, which I'm posting so that it
gets into the archives:

  Well, lets see...  If you used a "c" command and the system continued
functioning normally (i.e. didn't do a memory dump and reboot), then it
sounds like you hit the "Do" key [if using the LK keyboard and display]
or the system got a serial break [if using the serial console], which
causes the kernel debugger to be entered.  This is the "normal" way to
enter the debugger from the console when one needs to get to the debugger
to look at something while debugging.  I suppose there ought to be some
way to "disable" this feature for people who don't really need to enter
the debugger like this.  You can modify your kernel by locating the call
to Debugger() in dev/dc.c [for the 5000/200] and commenting it out.  This
will still leave DDB available if the system crashes, or if you don't need
DDB at all, you can remove that from your kernel configuration.

  If the system does do a memory dump and reboot after you enter the "c"
command, then the system probably paniced and dropped into DDB.  [The
entry to DDB on a panic can be disabled by using sysctl to change
ddb.onpanic to 0.  This can also be defaulted with a kernel option
DDB_ONPANIC=0 - which seems to be the default in the -current GENERIC
kernel.

  If DDB was entered on a panic, the primary information needed would be
the panic message.  Further information would depend upon what the panic
was.

--

Philip J. Tait.....AlliedSignal Engines, Phoenix, Az.....pjt@phxase.allied.com