[136] in linux-scsi channel archive
Re: BusLogic/HP-DAT Problems - Solved
daemon@ATHENA.MIT.EDU (Michael Weller)
Mon Apr 10 09:14:33 1995
Date: Mon, 10 Apr 1995 12:48:39 +0200 (MSZ)
From: Michael Weller <eowmob@exp-math.uni-essen.de>
To: linux-scsi@vger.rutgers.edu
Cc: "Leonard N. Zubkoff" <lnz@dandelion.com>
In-Reply-To: <9504081715.AA22377@pollux.exp-math.uni-essen.de>
> From: "Leonard N. Zubkoff" <lnz@dandelion.com>
> To: Angus Tyler <angus@honung.demon.co.uk>,
> Ed Randall <ed@orlando.demon.co.uk>,
> Julian Thonpson <jrt@miel.demon.co.uk>, linux-scsi@vger.rutgers.edu
> Subject: BusLogic/HP-DAT Problems - Solved
[...]
> In reading with the default blocksize of 10240, the SCSI Tape driver presents
> the host adapter with a request where the SCSI Command Descriptor Block
> comprises a READ_6 command for a variable size block containing a maximum
> length of 10240 bytes. However, the BusLogic Command Control Block is told to
> expect 32768 bytes. The READ command is executed by the DAT drive and a status
> of GOOD is returned. However, the BusLogic host adapter signals a data
> over/under run error since it didn't receive the amount of data it was told to
> expect. The SCSI tape driver then propogates this error.
>
> When the blocksize is set to 10752 (tar -b21), the SCSI CDB requests 10752
> bytes and the BusLogic CCB again expects 32768. However, in this case the DAT
> drive signals a CHECK CONDITION error as the block actually read was only 10240
> bytes long. The sense data for this error indicates that 512 bytes of data
> were not transferred, and the SCSI tape driver accepts this as a legitimate
> READ that returned 10240 bytes. The BusLogic host adapter may also signal a
> data over/under run for this command, but that is irrelevant since the
> underlying SCSI command also failed.
>
> My opinion is that the fundamental problem here is that the BusLogic driver is
> being fed inconsistent data. While one can turn off this error checking, I
> believe that is a bad idea. I believe the proper fix is the following patch to
> st.c which makes the arguments to scsi_do_cmd consistent with those in the SCSI
> CDB that is being executed:
[patch deleted]
Hmm... I tend to disagree... Though this may be a well working approach when
you use 10K tape blocks on your DAT and make tar write exactly 10K byte
blocks, I understand it will give severe problems at end of tape whenever
a command reads more than exactly one tape block.
I had this problem a long time ago with a simple QIC-150 tape and the
aha174x. It did on the end of most tape-archives fail with I/O error.
These came from the tape driver trying to fill it's tape buffers and
reading some data. However if the tape reaches an EOF mark it can only
return some 512 byte blocks not all requested and thus produces an underrun
which is definitely no error (though the driver claimed it was).
IMHO in general underruns are no errors, esp. for tapes.., things are
different in some situations (like this) or for disks, for example.
However the low-level driver can't know this. So it should not report
a fatal error and give the mid-level driver a chance to check for underruns
itself instead.
I think this condition can not occur when using variable block sizes..
but making the Buslogic driver support only variable block size tapes sounds
not like a good idea to me.
At that time I patched the aha174x driver to silently ignore underruns.
(I think they can still be detected by the calling mid level driver)
I'm not sure however if the tape does report CHECK CONDITION in this
case.. I would have to check the sources.
Seems to work like a charm since then. (was one of the latest patches
made to it, as far as I know)
I didn't look in the sources some time now but there must be a way to find
out how much bytes were actually read.. so the midlevel drivers are able to
check for it. (and the tape driver does so for sure)
Apart from that it is of course a good idea to make the low-level driver
expect only as much data as can be transferred as a maximum. This will
catch overruns earlier and be generally cleaner, so your patch has a point,
even though I still see problems with non-variable block sizes and the
Buslogic if it does handle underruns fatal.
Michael.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@aixrs1.hrz.uni-essen.de instead.)
