Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!goanna!escargot!otto!davidb
From: davidb@otto.bf.rmit.oz.au (David Burren [Athos])
Newsgroups: comp.os.386bsd.bugs
Subject: Tandberg 3600 tape drives [fix/hack]
Message-ID: <davidb.737953414@otto>
Date: 21 May 93 03:03:34 GMT
Reply-To: davidb@melb.cpr.itg.telecom.com.au
Organization: Royal Melbourne Institute of Technology
Lines: 102
NNTP-Posting-Host: otto.bf.rmit.oz.au
This is a description of the hack required to get my TDC 3640 SCSI tape
drive to talk to NetBSD-0.8. Thus it should equally apply to 386bsd
with Julian's SCSI subsystem. A patch file is appended to this article.
My TDC is an ex-IBM part, and the Inquiry data indicates a non-zero
option level (ie. a customised ROM). Thus if you have a TDC 3600, I
would like to hear from you (via email) as to whether this works for
you. Please include a copy of the Inquiry data as logged in
/var/log/messages.
Problem:
The st driver uses the Read_Block_Limits command to query the
drive's minimum and maximum block sizes. If these are non-zero
and not equal, the drive is assumed to support variable block
sizes (which is a reasonable assumption I would have thought :-).
This means that the Block Size field in the subsequent
Mode_Select is set to 0, meaning "use your default".
Otherwise the drive is assumed to have a fixed block size, and
the Block Size field is filled in with the "nominal block size"
returned by a Mode_Sense (and printed at boot time).
The TDC drive I have returns a minimum block size of 1 and a
maximum of 32k. This is contrary to the 3600 Reference Manual
which states that 512 bytes will be returned for both fields.
As a result, the drive returns an Illegal Request when the
Mode_Select command specifies a Block Size of zero. This value
is not valid for fixed block-size drives. Thus any attempt to
open the tape device fails.
My hack:
The Block Size field of the Mode_Select command is filled in with
the nominal block size for that drive irrespective of the minimum
and maximum block sizes returned by Read_Block_Limits.
With this hack, I can now use my 3640 to read and write QIC-120
tapes and read QIC-24 (and probably QIC-11) tapes. My Exabyte 8200
(which is a variable block-size drive) still behaves properly.
stattach() is also modified so that the minimum and maximum block
sizes are printed at boot time for reference.
I refer to this as a hack rather than a fix as I believe the
"proper" fix for this is to get the driver to recognise the
Inquiry string and look up a table of drive-specific rule
modifications, defaulting to "the standard SCSI way". This is
the behaviour of several other SCSI drivers I've seen. The problem
is that there isn't really a "standard way" in the world of tape
drives (or not that I've noticed anyway).
Please let me know how your Tandberg 36xx performs...
__
David Burren
davidb@melb.cpr.itg.telecom.com.au
+61-3-6343635
*** st.c.orig Fri May 21 11:43:05 1993
--- st.c Fri May 21 12:43:54 1993
***************
*** 165,170 ****
--- 165,175 ----
{
printf(" st%d: scsi tape drive, %d blocks of %d bytes\n",
unit, st->numblks, st->blksiz);
+ if(st_rd_blk_lim(unit,0))
+ {
+ printf(" min_block_size %d, max_block_size %d\n",
+ st->blkmin, st->blkmax);
+ }
}
else
{
***************
*** 1174,1181 ****
{
lto3b( st->blkmin , dat.blk_desc.blklen);
}
/* lto3b( st->numblks , dat.blk_desc.nblocks); use defaults!!!!
- lto3b( st->blksiz , dat.blk_desc.blklen);
*/
/*******************************************************\
* do the command *
--- 1179,1194 ----
{
lto3b( st->blkmin , dat.blk_desc.blklen);
}
+ else
+ {
+ /*
+ * This change to try to cope with mis-reporting
+ * Tandberg drives.
+ * - David Burren, May 1993
+ */
+ lto3b( st->blksiz , dat.blk_desc.blklen);
+ }
/* lto3b( st->numblks , dat.blk_desc.nblocks); use defaults!!!!
*/
/*******************************************************\
* do the command *
____
Fini