ACA handling for temp initiators - response

scheible at scheible at
Mon Jun 13 08:52:27 PDT 1994

   Regarding the third party operation with ACA note shown below.

   I have a concerns with allowing any initiator to handle the ACA.

1) If an second initiator handles the error, then error information to
   the first initiator (who saw the Check Condition status) is lost.
   This would result in a no problem found condition which is very hard
   to trace.

2) The preferred method (A) does not allow for multiple ACA conditions
   to be outstanding at once.  This is especially important to Async
   Event Reporting cases, where the error condition is reported to a
   group of initiators.  Each initiator has its own ACA condition that
   if only reset for itself when it issues a Clear ACA Condition
   message.  Other initiators could have their ACA conditions still

SAM QUESTION: If the condition states in 2) where AER is issued to a set
              of initiators.  If an initiator frees his ACA and his
              command is next on the queue, can his command execute,
              even if other initiators have ACA conditions?

John Scheible
Bldg 815,  Mailstop 4051
11400 Burnet Road
Austin TX, 75758
Voice: (512) 823-8208
FAX:   (512) 823-0758
EMail: scheible at
Date:         Fri Jun 10 15:27:09 1994
From: Gerry Houlder <Gerry_Houlder at>
Organization: Seagate Technology
Subject:      ACA handling for "temporary initiators"

This scenario was created in the context of XDWRITE command (from my XOR drive
command proposal, X3T10/94-111, that was passed out but not discussed at the
May SCSI Working Group meeting) but the same situation can occur on a COPY
command (which also can result in a temporary inititor). The problem is as

1) Initiator A sends a third party XDWRITE command to device B. The ACA bit is
set in the command bytes.
2) Device B sends an XPWRITE command to device C (in the course of the XDWRITE
operation) that ends with CHECK status. I presume the ACA bit was set in the
command bytes of the XPWRITE command also. This results in an ACA "allegiance"
|from device C to device B.
3) Device B sends REQUEST SENSE to device C to retrieve the sense bytes (or
receives the sense bytes as part of an autosense operation). Device B ends the
XDWRITE command with CHECK status (which results in an ACA "allegiance" from
device B to initiator A) and returns sense data describing the fault on the
third party drive (either as part of auto sense operation or inresponse to a
REQUEST SENSE from initiator A).
4) Initiator A now has sense data describing the problem on device C, but
cannot act to clear the problem because only device B can send commands (with
ACA tag, of course) to device C. How can we solve this???

A) My preferred method:
 Change the ACA tag rules so that the device can accept (and execute) an ACA
tag command from any initiator when the device is in the ACA state. This allows
the real initiator (which presumably if more able to correctly resolve the
error) to access the erroring device directly, with no other special operations

The drawback to this method is that the system must assume all initiators are
"well behaved" in that they will not issue an ACA tag command to a device that
returned ACA ACTIVE status unless that initiator received a previous CHECK
CONDITION status for a command involving that drive. An initiator that knows
about that device's failure should properly resolve the error and send a CLEAR
ACA message (or packet). It also means changes to SAM to allow this behavior.

B) The "transfer ACA" method:
Create a means for device B to transfer ACA allegiance to third party device A.
Device B would have to send a transfer ACA (message? packet? command?) that
would provide the address of device A. This would transfer the allegiance to
the device that is expected to clean up the error without letting any other
device have access to device C.

This works, but involves a lot more changes to SAM and to the protocol
documents to describe such a structure.

I hope everyone gives this some thought and lets me know their preference on
this. I will be giving a presentation on the XOR drive commands at the RAID
study group meeting at Hotel Sofitel in Bloomington, MN June 21 (during the
X3T11 meeting week), so this would be a good time for this discussion. I think
this must be resolved before SAM is finalized.
Gerry Houlder -- Gerry_Houlder at
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster at
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222

More information about the T10 mailing list