This message is from the T13 list server.
>>> [EMAIL PROTECTED] 04/15/02 10:52AM >>> YES! Thank you for sharing my reality. I had heard tape folk had a way for op x03 RequestSense, outside of the auto-sense of a CheckCondition, to report residue ... but I didn't appreciate the units were indeterminately bytes or blocks. What I really enjoy about Atapi is that the (allocationLength - actualLength) residue can be negative ... for example, an Atapi host that does copy 6 bytes In to a 5 byte buffer under whatever provocation, gives us a residue of -1, ouch. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> [EMAIL PROTECTED] 04/15/02 10:52AM >>> 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 ********************************************************************
