[3454] in linux-scsi channel archive
DAT drive problems... (Did I miss something?)
daemon@ATHENA.MIT.EDU (campbell@gear.torque.net)
Thu Mar 5 19:15:43 1998
From: campbell@gear.torque.net
To: linux-scsi@vger.rutgers.edu
Date: Thu, 5 Mar 1998 17:39:32 +0000
General enquiry about DDS DAT drives:
(appologies in advance for the low level detail)
I have been testing the JAZ Traveller (Iomega parallel port to SCSI
convertor) using a Digital TLZ09/Sony SDT-7000 (identity changed by a
DIP switch on the base.
The drive consistently gives an error after approx 330-380 kB has been
written to the device file (amount varies depending on the block size
used for "dd", block sizes from 512 bytes throught to 128k).
For example when I use "dd" without specifying a block size I get:
---------------------------------------------------------------------
666+0 records in 665+0 records out
---------------------------------------------------------------------
... and I am *NOT* joking about those figures. I had to take a second
glance to make sure. (the problem is repeatable and will ALWAYS fail
at that mark).
I have to unload and reload the base SCSI driver (ppa - the same one
as the parallel port ZIP drive) to reset the device. A power cycle of
the DAT drive also works but I have heard that is NOT a good thing to
do...
Now if I use "mt drvbuffer 0" to disable the builtin device buffering
I can write as much as I want to the tape. Using "mt drvbuffer 2"
fails (unsupported). Which leads me to the question:
"Why does the drive hang after 340 kb when
device buffering is enabled?"
From the detail I can gather from ppa (which I maintain) it appears
that the data block is written correctly to the DAT drive. However the
SCSI bus lines are such (!REQ, !BSY, CD, IO), that the drive appears
to be asking for more data. Prior to the offending command the drive
correctly sets the SCSI bus lines (!REQ, !BSY, !CD, !IO) after it has
received the expected amount of data. The result integer has the value
of 0x00000000 for all commands prior to the one that fails.
Is there something in the SCSI spec that I have missed?
What should the ppa device driver do when it encounters this problem?
(currently ppa returns DID_ERROR in the result if the device requests
more data than the buffer holds).
This occurs using the standard drivers in Linux 2.1.87.
Other information which may help in the diagnosis:
When I slow down the main ppa queue to a crawl the problem disappears.
This suggests that the data is leaving the device buffer faster than
ppa can supply it. Shouldn't the device return some code to suggest to
pause?
The ppa driver operates in "single initator mode" (it has the
intelegence of bi-directional data buffer, seriously the adapter is a
programable array logic [PAL] chip). Due to design limitations it does
not "hear" any SCSI messages.
Due to the percieved "black magic" that occurs in the mid level scsi
modules, the ppa driver does not attempt any sense requests. (poking
around some of the other routines indicates there is no easy way to
send a command: eg here is the command and data buffers, go fetch).
Any help would be greatly appreciated.
David Campbell
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
