> I am installing an old dec tz30 (DLT tape). I am having some problems.
TZ30? The DLT series start with TZ86 (2.6 GB) or possibly TZ85 (?)
This sounds like some kind of TK30/TK50/TK70 stuff (really ancient stuff,
predecessor of the DLT series, some of the first DLT models supported
READING TK50 media, newer DLT drives doesn't support that).
A web-search suggests that this is indeed some kind of TK50-type
drive, supporting at least TK50 media, the 95 MB somebody quotes
sounds right for TK50?
Now, something with a TZ should at least be SCSI based, but it sounds
extremely old, and *could* have a non-standard SCSI implementation
that wasn't expected to be used against anything other than VAX3100
with VMS or Ultrix :-)
> The tape is on id=2. I am running 2.1.125 vanilla.
>
> The command I am issuing is a simple "mt -f /dev/st0 rewind"
>
> 1) The unit does not give a vendor id, yet /proc/scsi/scsi shows
> some. It actually shows the info from the lower id.
[...]
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
> Vendor: SEAGATE Model: ST31200N Rev: 8648
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 02 Lun: 00
> Vendor: SEAGATE Model: ST31200N Rev: 8648
> Type: Sequential-Access ANSI SCSI revision: 01
Hmm, yes this looks "interresting" :-) Looks like proc/scsi/scsi
driver might have forgot to clear the fields between the units?
> 2) Any attempt to access the tape gives a scsi error. I need to
> know if this is a real drive problem of is the driver failing
> to talk to this unit which seems to have a strange scsi
> implementation.
[...]
> Oct 12 12:09:37 eyal kernel: Vendor:
> Model: Rev:
> Oct 12 12:09:37 eyal kernel: Type:
> Sequential-Access ANSI SCSI revision: 01
[...]
> Oct 12 12:09:37 eyal kernel: Vendor: ARCHIVE Model: VIPER 150
> 21247 Rev: -005
> Oct 12 12:09:37 eyal kernel: Type:
> Sequential-Access ANSI SCSI revision: 01
Hmm, both these claim SCSI-1, but it looks like the TZ30 doesn't
implement all the stuff that the Archive does. *I* wouldn't trust
something that didn't report correct information there.
The error looks like it *COULD* be associated with target disconnects,
and the log also says the drive rejected synchronous mode.
Hence it MIGHT work if you disable sync transfers and disconnects
against the drive, but it's not something you WANT to do! A SCSI unit
that doesn't support disconnect isn't something you'd want near
anything important, especially not when the unit in question is a
tape-drive!
A tape-drive with disconnect disabled hangs the whole SCSI bus when
processing commands. As an extreme example, for a rewind it would hang
until it was finished with the rewind, say 30s+! (probably more, how
fast is a TZ30?) Ouch.
I wouldn't be surprised if operations to other SCSI units on the same
SCSI-bus had started timing out by then, and given that you have
SCSI-disks on the same SCSI-chain that could be pretty bad (lost data).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/