FCP_RESID_OVER question

Robert Snively rsnively at brocade.com
Thu Jan 17 21:01:50 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
*

> I wish to get some clarification about RESID_OVER.
> 
> In FCP-2 spec, draft rev.7, I found, in 9.3 FCP_DATA IU, the 
> sentence :
> "If the command requested that data beyond FCP_DL be transferred, 
> the FCP_RSP_IU shall contain the FCP_RESID_OVER bit set to one"
> 
> In the case of a SCSI CDB containing an insuffisent 
> Allocation length, but 
> with FCP_DL equal to this Allocation length, do I get a 
> FCP_RESID_OVER 
> Status (due to the troncation of returned data) or do I get a 
> zero Status 
> (due to FCP_DL = Allocation length) ?
> 

If I interpret your question correctly, you will not
get a residual bit set, but you will have CHECK CONDITION in the
FCP, with sense data indicating an incorrect length.

> In other words, if FCP_DL always equals Allocation length (of 
> SCSI CDB), 
> is it possible to get a FCP_RESID_OVER status ?

The allocation length is actually a calculated value based
on number of blocks and block size (for disks).  If the
driver is set up incorrectly, the predicted allocation
length (calculated by the driver using the wrong block length) will
match the FCP_DL, but will not match the actual
allocation length (which is calculated by the disk drive
depending on its known properties).  In devices where the
actual allocation length is exposed, I believe you are
correct.

Basically FCP_RESID is designed to detect cases where the
software that prepares the CDB and the software/firmware that
prepares the DMA space are not working from the same assumptions.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list