Date: Wed, 17 Jul 1996 13:06:32 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@freebsd.org Cc: jbh@labyrinth.net.au (John Hartley) Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 Message-ID: <199607171106.NAA03732@uriah.heep.sax.de> In-Reply-To: <199607160641.QAA13198@minotaur.labyrinth.net.au> from John Hartley at "Jul 16, 96 04:41:25 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As John Hartley wrote:
> >>> Output <<<
>
> Present Mode: Density = 0x00 Blocksize = 1024 bytes
> ---------available modes---------
> Mode 0: Density = 0x00 Blocksize variable
> Mode 1: Density = QIC-320 Blocksize variable
> Mode 2: Density = QIC-150 Blocksize variable
> Mode 3: Density = QIC-120 Blocksize variable
Ick. This is weird (and it cannot work this way). Neither this
blocksize nor this density will be accepted by the drive. As long as
you're getting this, all other attempts are in vaine.
However, this looks as if the `rogue' code wouldn't work as expected.
(Sorry, i cannot reproduce this, this code has been taken out
meanwhile. The entire rogue handling has been moved out to
scsiconf.c, that's what is #ifdef NEW_SCSICONF for you.)
Something like
mt -f /dev/st0ctl.0 blocksize 0
mt -f /dev/st0ctl.0 density 0x15
is the least that must work. Try experimenting with this.
> >I wonder whether we should always use the following kludge:
> >
> >@@ -1530,7 +1530,9 @@
> > scsi_cmd.length = dat_len;
> > dat.header.blk_desc_len = sizeof(struct blk_desc);
> > dat.header.dev_spec |= SMH_DSP_BUFF_MODE_ON;
> >- dat.blk_desc.density = st->density;
> >+ dat.blk_desc.density =
> >+ st->density? st->density:
> >+ 0x7f /* use previous density */;
> > if (st->flags & ST_FIXEDBLOCKS) {
> > scsi_uto3b(st->blksiz, dat.blk_desc.blklen);
> > }
> >
> >
> >
>
> I didn't try this as the previous test failed!!
Hmm, no, if you kill the rogue entry, the above _should_ work
nevertheless. (As long as the rogue entry is there, it seems the
kernel uses 1024 byte blocksize, but i remember that this wasn't the
case before for your drive.)
> I guess the question is is what is it that the FreeBSD drivers are doing
> that is different from the dos ASPI and Windows NT tape driver???
The BSD driver should perhaps by default not even try to MODE SELECT
the drive. That's what it is constantly getting wrong in your case.
Look here:
> Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes]
> Jul 16 17:09:38 qwiff /kernel: ------------------------------
> Jul 16 17:09:38 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00
> Jul 16 17:09:38 qwiff /kernel: ------------------------------
That's the interesting line. It should actually look:
> Jul 16 17:09:38 qwiff /kernel: 000: 00 00 10 08 15 00 00 00 00 00 00 00
^^ ^^
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607171106.NAA03732>