Hi,
We have just received an XP1000 and a TLZ10 DAT DDS3 tape drive. The problem
occurs when I run a backup script (this script has been around for a while).
The script has run on numerous versions of DU or Tru64 from v3.2 upto 4.0F.
The sequence of commands that gets it in a twist looks like this
************ start of snippet****************
echo "Command is: "$COMMAND >> $TMPLOG
echo "Starting rdump or dump in remote shell..." >> $TMPLOG
sleep 10
eval $COMMAND 2> $DUMPTMP
************ end of snippet****************
This sequence translates to the following (exerpt from the log file)
************ start of snippet****************
Command is: /sbin/vdump -N -U -0 -u -f /dev/ntape/tape0_d1 /local
Starting rdump or dump in remote shell...
path : /local
dev/fset : /dev/disk/dsk0h
type : ufs
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: Dumping 858958067 bytes, 597 directories, 16087 files
vdump: Dumping regular files
vdump: Status at Thu Sep 21 19:15:01 2000
vdump: Dumped 565330614 of 858958067 bytes; 65.8% completed
vdump: Dumped 334 of 597 directories; 55.9% completed
vdump: Dumped 8555 of 16087 files; 53.2% completed
vdump: Status at Thu Sep 21 19:17:10 2000
vdump: Dumped 859264994 of 858958067 bytes; 100.0% completed
vdump: Dumped 597 of 597 directories; 100.0% completed
vdump: Dumped 16087 of 16087 files; 100.0% completed
vdump: Dump completed at Thu Sep 21 19:17:10 2000
Ending backup of /local on yoda at 19:17:10
Starting backup of /yoda1 on yoda at 19:17:10
--------------------------------------------------
Command is: /sbin/vdump -N -U -0 -u -f /dev/ntape/tape0_d1 /yoda1
Starting rdump or dump in remote shell...
************ end of snippet****************
At this point the command returned some form of IO error, which was notified
via the mail system in the following way -
************ start of snippet****************
============================ Translation =============================
Sequence number of error: 1492518165
Time of error entry: 21-Sep-2000 17:53:55
Host name: yoda
SCSI CAM ERROR PACKET
Controller type: DISK
SCSI device class: UNKNOWN
Bus Number: 0
Target number: 7
Lun Number: 7
Name of routine that logged the event: isp_mailboxcomplete
Event information: Timeout on mailbox command completion - scheduling chip
reinit
======================================================================
************ end of snippet****************
So then I put "mt status" commands between the two vdump requests and ran
the script again. This time the second vdump worked but the "mt status"
command returned something like
************ start of snippet****************
Command is: /sbin/vdump -N -U -0 -u -f /dev/ntape/tape0_d1 /yoda1
Starting rdump or dump in remote shell...
*** Status of tape drive befor dump
/dev/ntape/tape0_d1: I/O error
path : /yoda1
dev/fset : /dev/disk/dsk2c
type : ufs
vdump: Date of last level 0 dump: the start of the epoch
************ end of snippet****************
this is followed by the rest of a valid vdump output.
It would appear that the controller has been left in a bad state (judging by
the mail message which refers to target 7 on bus 0) at the end of the vdump,
and the controller somehow is able to correct itself after an "mt" command
is issued (even though that command fails). The controller doesn't seem to
be left in a bad state by the mt commands, because I can issue more than 1
mt command with no problems and I can issue mt commands before the first
vdump process with no problems.
I'd be gratful for any comments that might shed some light on what is going
on.
Dennis
######################################
Dennis Macdonell
Systems Administrator
AUSLIG
mail: PO Box 2, Belconnen, ACT 2617
email: mcdonell_at_auslig.gov.au
ph: 61 2 6201 4326
fax: 61 2 6201 4377
######################################
Received on Thu Sep 21 2000 - 11:12:18 NZST