Queuing and ACA

Joseph C. Nemeth jnemeth at concentric.net
Tue May 5 21:46:34 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Joseph C. Nemeth" <jnemeth at concentric.net>
-----Original Message-----
From: James Smart USG <smart at zk3.dec.com>
To: jnemeth at concentric.net <jnemeth at concentric.net>; t10 at Symbios.COM
<t10 at Symbios.COM>
Date: Tuesday, May 05, 1998 8:24 PM
Subject: Re: Queuing and ACA

>* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>* James Smart USG <smart at zk3.dec.com>
>Re: the purpose of ACA ACTIVE - this is the basic notification to the
>initiator to initiate recovery. If you pile the commands up - the faulting
>initiator is never told to start recovery (issuing ios w/ the ACA active
>indicator) followed by a CLEAR ACA to turn the condition off. BUSY only
>implies the same action if there is no recovery function to perform
>(which is true on the non-faulting initiators). An example of a recovery
>function is one in which the initiator wants to be notified of a recovered
>media error, so it can they query or change the device and/or media state,
>before allowing the device to continue flushing its command quue.
>-- James

But the *faulting* initiator already knows about the need for recovery,

a) it must have set the NACA bit for the command that faulted, meaning this
is a command with some specialized recovery options in the first place, and
b) it must have received (or at least been sent) the CHECK CONDITION or
TERMINATED status from the NACA command.

The faulting initiator gains nothing in particular from having some
subsequent commands (already "in the pipeline" for execution somewhere in
the initiator driver layers, but not yet delivered to the target) rejected
with ACA ACTIVE, while other subsequent commands (that have already made it
into the target queue) are held pending release of the ACA condition.
Non-faulting initiators gain nothing in particular from the ACA ACTIVE
status, because there isn't a thing they can do about the ACA condition. The
only thing I immediately see is that rejecting commands prevents the queue
|from getting packed with more and more commands while the queue itself is
frozen, and perhaps thereby prevents a queue overflow. But a queue overflow
just means BUSY status, try again later, so who really cares if the queue

* 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