SCSI-3 FCP ACA/QErr abort process

Joseph Carl Nemeth jnemeth at concentric.net
Fri Aug 22 14:37:49 PDT 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Joseph Carl Nemeth <jnemeth at concentric.net>
*
I am having a hard time determining exactly what it means for a target to 
"abort" a task in the case of the ACA condition with the Mode Select QErr 
bit set to 1. I would appreciate a response from anyone who knows exactly 
how this is supposed to work.
There appear to be two very different kinds of "abort" actions.
The first kind of "abort" is in response to any Task Control Function that 
aborts established tasks. In this case, it seems clear from the SCSI-3 SAM 
that once the Function Complete response is made for the Task Control 
Function itself, the aborted tasks are simply blown away -- they must not 
have any further interactions with the initiator. Specifically, the target 
will not send any more FCP_XFER_RDY, FCP_DATA, or FCP_RSP IUs to the 
initiator for any task that has been aborted, and therefore, cannot return 
any kind of status or autosense data for those tasks.
The second kind of "abort" is in response to certain classes of error that 
are detected by the target. One example is the "overlapped command" 
condition, in which an initiator sends two overlapped Untagged commands. In 
this case, it seems clear that both commands are actually "terminated" 
rather than "aborted," completing (albeit prematurely) with Check 
Condition/COMMAND ABORTED/Overlapped Commands Attempted error status -- the 
implementor's note makes it clear that the aborted (first) command may need 
to report a residue, and I don't know how it would do this in FCP without 
being able to post its status and autosense data.
How, then, is the QErr "abort" handled? If there are multiple Simple (or 
Untagged) queue commands in the enabled state for a logical unit, and an 
ACA condition occurs due to an error on one of them, they all go from the 
enabled to the blocked state, and if the QErr flag is set, they must all be 
"aborted." Is this a silent abort, as though a kind of Abort Task Set had 
been issued from the host, or is it a noisy abort, in which each command 
actually terminates and returns error status? If the former, how is 
catastrophic data loss avoided? If the latter, exactly what status and 
sense data is returned? And how does that status interact with the Unit 
Attention condition for other (non-faulting) initiators?
Any assistance in understanding this would be appreciated.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list