Exabyte locks on long Dumps

[Glenn Deitiker]

We recently installed a second Sun Ethernet board in a sun 3/280.  Shortly
thereafter, our 8mm tape system (Artecon) started failing during dumps of
large partitions (600Mb).  The error messages are:

vmunix: st1:  failed cmd =  a  0  0  fc  0  0
vmunix: st1 error:  sense key(0x4): hardware error
vmunix:            sense = 70  0  4  0  0  0  0  12  0  0  0  0  0  0  0  0  0  5  f2  0  1  0  0  1c  a8  61  0  0
vmunix: 
vmunix: st1:  sttimer: I/O request timeout
vmunix:    last phase= 0x87 (Cmd complete MSG)
vmunix:    csr= 0x1407  bcr= 0  tcr= 0x4
vmunix:    cbsr= 0x0 (BUS FREE)  cdr= 0x0  mr= 0x0  bsr= 0x0
vmunix:    target= 5, lun= 0    DMA addr= 0x358  count= 2 (64512)
vmunix:    cdb=    a  0  0  fc  0  0
vmunix: si_deque:  can't find: target 5, lun 0
vmunix:   que:
vmunix: si0:  resetting scsi bus
vmunix:    last phase= 0x87 (Cmd complete MSG)
vmunix:    csr= 0x1407  bcr= 0  tcr= 0x4
vmunix:    cbsr= 0x0 (BUS FREE)  cdr= 0x0  mr= 0x0  bsr= 0x0
vmunix:    target= 5, lun= 0    DMA addr= 0x358  count= 2 (64512)
vmunix:    cdb=    a  0  0  fc  0  0

Oddly enough, the smaller 100-200Mb partitions continue to dump without a
problem, as do the remote dumps (100-300Mb).

At the encouragement of Artecon, we placed our ethernet board in front of
the SCSI, 7053, and ALM boards.  This should have given the ethernet
priority on the bus; in addition, the new SCSI driver from Sun was
installed to no avail. (It did fix the bus error bug)

It may also be notable that all three of the successful dumps occured in
the wee hours of the morning, when ethernet trafic is at its least.

This problem has made it extreamly difficult to back up our database,
which must be running during the dumps (ie. no single user dumps).  We
would appreciate any information available for solutions or similar
problems.

Thanks.