Hi,
I'm having a bit of a problem with a sony DDS4 SDT-1000 DAT unit on a DS20E
running v5.0A. We had purchased 2 of these units to replace Compaq DDS3
units that came with a DS20E and an XP1000. Both these Compaq systems are
running v5.0A. Both units are internally mounted.
The unit in the XP1000 is the only device on that scsi bus and has no
problems at all. Here is hwmgr -v devices
59: /dev/tape/tape0 SONY SDT-10000 bus-0-targ-5-lun-0
However the unit in the DS20E, shares the bus with a few other external tape
devices, vis
65: /dev/ntape/tape3 QUANTUM DLT7000 bus-4-targ-5-lun-0
66: /dev/changer/mc0 Powerstor L200 bus-4-targ-1-lun-0
67: /dev/ntape/tape4 QUANTUM DLT7000 bus-4-targ-0-lun-0
71: /dev/ntape/tape0 SONY SDT-10000 bus-4-targ-4-lun-0
and this unit has had no end of problems. Both units are generally using
DDS3 tapes rather than DDS4 tapes. The unit in the DS20E is basically just
used for backups, whereas the one on the XP1000 is used by users for writing
raster images and backups. From memory, I believe the DAT unit used to work
on the DS20E when there was only the internal DAT and 1 external DLT drive,
but around the time I connected 2 external DLT7000 unit, the thing started
to have problems. Even now with the current devices on bus-4, small tests
using tar seem to work fine, and generally the backup script seems to work
for /, /usr, /local, but then for some reason the thing dies.
When running the backup script (which includes about 8 different
partitions), the syslog reports via uerf (not many people still use the old
uerf command, but I believe its almost as decent as decevent)
ROUTINE NAME ctape_iodone
----- CAM STRING -----
Status = CMP but resid not NULL
----- CAM STRING -----
ERROR TYPE Possible Software Problem -
Impossible
_Cond Detected
Then the bus gets reset and things like that, and at the end of the whole
thing the DS20E doesn't want to know about the tape drive. That's true, if I
enter a command like "mt status" (default tape0), it reports that there is
no such device. The computer has to be rebooted before it wants to talk to
the tape drive again. Even the control buttons on the tape drive don't work
until the reboot (ie the tape is stuck in the drive, until the machine is
rebooted). I didn't think computers were allowed to get pissed off.
vdump reports:
vdump: unable to write to device </dev/ntape/tape0_d1>; [5] I/O error
vdump: unable to prompt input for retry on device; [25] Not a typewriter
It doesn't seem to be the tape drive as I swapped the tape drives between
the DS20E and the XP1000 (and then had to somehow get the replacement drive
to be recognised as tape0, what stuff around that is). The tape drive that
was failing in the DS20E is now working fine in the XP1000 and the one that
was working in the XP1000 is now failing in the DS20E. I suspect the scsi
card, or the scsi software, or perhaps the length of the scsi bus, or even a
conflict between differential and single ended (but I don't quite understand
how you check for that sort of thing), or the terminators, or that the DS20E
just doesn't like the Sony SDT1000 (not necessarily in that order).
I suppose I could just disconnect the external drives and then run the
backup script. If that works, I could just replace the scsi card with a dual
scsi.
The external devices don't seem to be affected.
At the time I purchased the DDS4, I don't think Compaq were shipping any
DDS4s, however, I believe they have now declared them compatible.
If anyone can shed any info on this I would be more than happy to test their
comments.
Dennis
######################################
Dennis Macdonell
Systems Administrator
National Mapping Division, Geoscience Australia
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 Mon Feb 04 2002 - 08:16:14 NZDT