Re 3: CA_ACA Proposal 97-225r0.DOC

Gene Milligan Gene_Milligan at
Fri Sep 5 12:37:37 PDT 1997

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* Gene Milligan <Gene_Milligan at>
Let's try this again:

The CA_ACA proposal is not the source of the change to deferred errors.

The current SPC wording is: "b) If it is possible to associate a deferred error 
with a causing initiator and with a particular function or a particular subset 
of data, and the error is either unrecovered or required to be reported by the 
mode parameters, a deferred error indication shall be returned to an 
application client on the causing initiator. If an application client on an 
initiator other than the causing initiator attempts access to the particular 
function or subset of data associated with the deferred error, a BUSY status 
shall be returned to that application client in response to the command 
attempting the access."

 This wording is from SCSI-2. It is describing the time between the device 
detecting that it has a deferred error to report and when the causing initiator 
has sent a command to the device as a result of the deferred error CHECK 
CONDITION to clear the Contingent Allegiance. The response to other initiators 
in SCSI-2 was BUSY. SCSI-3 changed the response during ACA to CHECK CONDITION 
ACA Active. Subsequently the NACA bit was added to accommodate SCSI-2 HBAs and 
the response became dependent upon the NACA bit.

Change included in CA_ACA proposal:
In reviewing the places where ACA conditions were dealt with I noticed that 
several did not pick up the differences in behavior that depend upon NACA. One 
of those was the deferred errors. Consequently I attempted to include the 
omissions in implementing the NACA change.

My prior response to Tom:
I said the commands from the other initiators would result in a CHECK 
CONDITION. A more complete answer should have been: If NACA=1 new commands from 
the other initiators will result in CHECK CONDITION ACA Active. If NACA=0 new 
commands from the other initiators will impinge upon BUSY. Queued commands 
would depend upon reservations, SEXE, QErr, and ordering. They would also 
depend upon whether or not the error is still unrecoverable and the error 
handling parameters for the non-causing initiator After the BUSY is gone a 
CHECK CONDITION for new commands would have equivalent variables to the queued 
commands except for the SEXE and Qerr fields.

My additional response to Tom:
I fully understand why it is dangerous to ignore an error condition that could 
be reported. That is why I assumed those that use ordering would want it to 
apply to other initiators. I think the tools are there for safe operation and 
those that are providing safeguards not visible to the device may use the tools 
in a manner that appears unsafe to the device.

But I do not understand what the difference is to the non-causing initiators 
between an error reported to the causing initiator with status for the causing 
command and an error reported to the causing initiator as a deferred error. The 
non-causing initiators have no visibility to tell which type of error report 
had been made. Consequently I assume they would expect the same result with a 
command being sent to an address that had just had an error.

Tom, I hope you will be in Nashua Tuesday.

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list