This message is from the T13 list server.
For the benefit of the non-ATAPI members of the audience,
may I add a few definitions and comments about ATAPI and 'residue' ?
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - -- - - - - -
Any SCSI or ATAPI command that may result in data transfer contains a count
(in the CDB) of the maximum number of BYTES <OR> BLOCKS that are expected
to be transferred. This is known as the 'ALLOCATION LENGTH'.
For some commands, the 'allocation length' is in terms of BYTES,
and for some, it is a number of BLOCKS of the currently defined 'block
size'.
(The current blocksize is returned by the MODE SENSE command, and may be
changed by the MODE SELECT command.)
For a host-READ operation, the device is allowed to transfer UP TO
but not more than the indicated allocation length. (Less is OK)
For a host-WRITE operation the device is allowed to accept UP TO
but not more than the indicated allocation length. (Less is OK)
Following the completion of such an ATAPI data transfer command,
if the next command is REQUEST SENSE, some of the data returned
in the REQUEST SENSE response indicates the 'residue' = 'residual count'
RESIDUAL COUNT = ALLOCATION LENGTH - actual length
(in compatible units)
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - -- - - - - -
Here's where the 'fun' starts, however.... (for PIO <and> DMA)
>>>>> Assumption: The device correctly implements the commands and
accurately
>>>>> calculates and reports the residue.
>>>>> (This is NOT always a valid assumption).
If the command has an allocation length in BYTES, then you can accurately
tell if the correct number of bytes (even <or> odd) were transferred, by
examining
the residue.
<<<BUT>>>
if the command has an allocation length in BLOCKS, then you CAN-NOT
accurately determine if the correct number of BYTES were transferred.
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - -- - - - - -
COMMON problems include:
a) the device does not accurately count the bytes transferred.
b) the device counts correctly, but reports a different number
c) the device implements odd-byte transfers incorrectly
d) the host implements odd-byte transfers incorrectly
e) device firmware sets-up for the correct transfer, but
its hardware performs the transfer incorrectly.
f) host and device perform the transfer correctly, but the host driver
bungles something.
g) you have an 'intelligent' SCSI adapter that tells the host driver
different information than actually occurred.
h) (supply any number of your own horror stories)
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - -- - - - - -
- Jim Hatfield
Overland Data Inc.
********************************************************************
Get it all in Overland's revolutionary new Neo tape library.
Non-stop operation. Expansion on demand. Easy to use
For more information on Neo:
http://www.overlanddata.com/neo
For more information on Overland:
http://www.overlanddata.com
********************************************************************
