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