Re 3: CA_ACA Proposal 97-225r0.DOC
Gene_Milligan at notes.seagate.com
Fri Sep 5 12:37:37 PDT 1997
* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Gene Milligan <Gene_Milligan at notes.seagate.com>
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 symbios.com
More information about the T10