Precedence of SCSI-3 Status (X3T10/94-171R0) - resend

Charles Monia, SHR3-2/W3, 237-6757 30-Aug-1994 1815 monia at starch.enet.dec.com
Tue Aug 30 15:13:16 PDT 1994


My apologies to anyone receiving this for the second time. I am resending due to 
a problem with our gateway which may have caused loss of the original message.


Charles Monia
==================================================
From:	STARCH::MONIA        "Charles Monia, SHR3-2/W3, 237-6757"   26-AUG-1994 
16:44:43.77
To:	scsi_reflector
CC:	MONIA
Subj:	Precedence of SCSI-3 Status (X3T10/94-171R0)

From:     Charles Monia
     Digital Equipment Corporation

To:  Members of X3T10

Subject:  Precedence of SCSI-3 Status (X3T10/94-171R0)

In a multi-initiator environment,  there is a potential deadlock, as shown
below, which may require a hard reset to clear:

     1.   Initiator A reserves a logical unit and issues a com-
          mand which causes a unit attention condition for all
          initiators.

     2.   Initiator B sends a command to the logical unit.

     3.   Instead of terminating the command with a status of
          RESERVATION CONFLICT, the logical unit chooses to
          report the unit attention by returning CHECK CONDI-
          TION status.

Because of the ACA caused by B, initiator A cannot issue any more
commands. Conversely, since the logical unit is reserved by A, initiator
B cannot issue a command to clear the condition. If CLEAR ACA is not
implemented, the condition will have to be cleared through a hard reset.

In the example, completing the command from B with RESERVATION
CONFLICT instead of CHECK CONDITION status would have avoided
the problem.  The current text in SAM, rev 15, clause 6.6.5 addresses
the issue as follows:

"If an initiator issues a command other than INQUIRY or REQUEST
SENSE while a UNIT ATTENTION condition exists for that initiator
(prior to generating the ACA condition for the unit attention condition),
the LUN shall not perform the command and shall report CHECK
CONDITION status unless a higher priority status as defined by the
LUN is also pending (e.g. BUSY or RESERVATION CONFLICT.)"

I believe this text, which is ambiquous and can be construed to specify
optional behavior, should be replaced with the following:

"6.2 Status
.......
6.2.1 Status Precedence

If more than one condition applies to a completed task, the report of a
BUSY, RESERVATION CONFLICT, ACA ACTIVE or TASK SET FULL
status, shall take precedence over the return of any other status for
that task."
 






More information about the T10 mailing list