[133] in linux-scsi channel archive
BusLogic/HP-DAT Problems - Solved
daemon@ATHENA.MIT.EDU (Leonard N. Zubkoff)
Sat Apr 8 13:08:33 1995
Date: Sat, 8 Apr 1995 09:16:39 -0700
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
I believe I've finally analyzed and corrected the precise cause of the failures
using BusLogic controllers with HP DAT drives and variable block sizes (setblk
0). As I suspected, the BusLogic driver itself is not really at fault, but the
BusLogic host adapters have error checking code that is less permissive than
other cards.
To recap, after writing a tape with tar's default blocksize of 10240 using a
"tar -cvf /dev/st0 <filename>" command, the command "tar -tvf /dev/st0" will
fail with an I/O error, whereas using a blocksize one larger with the command
"tar -b21 -tvf /dev/st0" will succeed in reading the tape. Here's my analysis
of what's happening.
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:
--- linux/drivers/scsi/st.c- Mon Apr 3 22:05:34 1995
+++ linux/drivers/scsi/st.c Sat Apr 8 09:10:15 1995
@@ -1063,8 +1063,7 @@
SCpnt->request.dev = dev;
scsi_do_cmd (SCpnt,
(void *) cmd, (STp->buffer)->b_data,
- (STp->buffer)->buffer_size,
- st_sleep_done, ST_TIMEOUT, MAX_RETRIES);
+ bytes, st_sleep_done, ST_TIMEOUT, MAX_RETRIES);
I do not have access to an HP DAT drive, so I would appreciate it if folks
having trouble with BusLogic controllers and HP DAT or other tape drives would
apply this patch and let us know if this fully corrects the problems. Since
the SCSI CDB itself requests that at most "bytes" bytes of data be transferred,
I don't see how this change could adversely affect any other drive/controller.
Leonard
