system crashes trap type 8

[wls at astrovax.UUCP]

  We have seen this problem ourselves with a panic trap type 8 with an address
in the interrupt handler for dz3, followed by a series of trap type 2's.
This is very frustrating as there is no core dump, the system is just too sick.
This was solved (rather it was shoved under the rug) by removing all terminals
from dz3, which was possible as we had just acquired a DH11 emulator from
Emulex and had surplus ports.  We have not touched the DZ driver.
  However, the fun continues.  Periodically we get a trap type 8 followed by
a string of trap type 2's, again with no core dump.  This time the trap type
8 is in ubasetup() and the trap type 2's are coming from the RTE instruction
of the console output interrupt routine (we have a Vax 750). Clearly the
stack is messed up.  This usually occurs when running some device that does
unbuffered ("raw") dma. Also we periodically have a "dup iodone" panic again
followed by a string of trap type 2's coming from the console output interrupt
routine, also provoked by raw dma (usually from the Versatec).  These are
frustrating bugs as they occur too infrequently to provoke a major effort
(though the "dup iodone" bug when it does occur, often then happens several
times that day), and produce no core dump, making them hard to track down.  The
only thing I can think of doing is to insert some code to catch these panics in
their tracks, not to let them print out (because the system does not seem
to be able to print then) but to hang in a tight loop to let me examine
things from the console.
  Are there known bugs in the panic routine for which there have been
fixes reported? Our copy of 4.1 BSD dates from June 1982 and I have only
been reading Usenet since April this year.
  William L. Sebok {allegra,cbosgd,decvax,ihnp4,kpno}!astrovax!wls