UA interlock & multiple initiators
Ralph Weber
ralphoweber at compuserve.com
Fri Feb 21 05:15:37 PST 2003
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
*
Having reviewed this discussion and the UA_INTLCK_CTRL descriptions
in SAM-3 and SPC-3, I believe that an editorial change along the
lines of Mallikarjun's original proposal is the most appropriate
of the choices that have been discussed.
Adding cross references in SAM-3 simply ties together two sets of
requirements that are related only by virtue of being controlled by
the UA_INTLCK_CTRL field in the Control mode page. The requirements
are real and must be observed. However, it is the definition of the
UA_INTLCK_CTRL field in the Control mode page that should tie them
together, not SAM-3.
With that in mind, I have noted the following editorial change
for SPC-3 R12 in the first sentence of the 11b definition in
the UA_INTLCK_CTRL table (table 226):
change from:
The logical unit shall not clear any unit attention condition
reported concurrently with a CHECK CONDITION status and shall
establish a unit attention condition when a task is terminated
with BUSY, TASK SET FULL, or RESERVATION CONFLICT status.
to:
The logical unit shall not clear any unit attention condition
reported concurrently with a CHECK CONDITION status and shall
establish a unit attention condition for a SCSI initiator port
that is the source of a task being terminated with BUSY, TASK
SET FULL, or RESERVATION CONFLICT status (see SAM-3).
All the best,
.Ralph
Mallikarjun C. wrote:
>
>* From the T10 Reflector (t10 at t10.org), posted by:
>* "Mallikarjun C." <cbm at rose.hp.com>
>*
>Ed, Thanks for the note.
>
>I recall starting from SAM-3 - a quick search for "UA interlock" or "interlock"
>did not yield any matches, and clause 5.9.7 that discusses Unit Attention wasn't
>specific on this either. But I now see that I should have searched for UA_INTLCK_CTRL.
>I can now see that SAM-3 is defining the precise semantics of this bit field - so at
>this point, my only recommendation would be to move the definition of those semantics
>from the Status clause (5.3) to 5.9.7, or at least add a cross-reference from the latter.
>
>Thanks!
>--
>Mallikarjun
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions
>Hewlett-Packard MS 5668
>Roseville CA 95747
>cbm at rose.hp.com
>
>----- Original Message -----
>From: "Edward A. Gardner" <eag at ophidian.com>
>To: "Mallikarjun C." <cbm at rose.hp.com>
>Cc: "T10 Reflector" <t10 at t10.org>
>Sent: Thursday, February 20, 2003 9:47 AM
>Subject: Re: UA interlock & multiple initiators
>
>
>
>
>>The intent was that a UA interlock would only be for the individual I_T_L
>>nexus that had a failed command. That is, your "latter" case.
>>
>>Please check SAM-3. SPC-3 only states the mechanism for enabling /
>>disabling UA interlock. SPC-3 is not supposed to describe how it
>>works. That is in SAM-3 (and under the principle of specifying things in
>>one place, should not be redundantly specified in SPC-3). If you think
>>SAM-3 is ambiguous or unclear, we'll fix it.
>>
>>At 16:43 14-02-2003, Mallikarjun C. wrote:
>>
>>
>>>* From the T10 Reflector (t10 at t10.org), posted by:
>>>* "Mallikarjun C." <cbm at rose.hp.com>
>>>*
>>>In looking through SPC-3 r09 for UA interlock (clause 8.4.6, table 223)
>>>semantics, we couldn't find the answer to this question:
>>>
>>>When UA interlock is enabled (UA_INTLCK_CTRL = 11b), does the
>>>device server establish a interlocked-UA condition for all initiators, or just
>>>for the initiator whose task just terminated with BUSY/TASK SET FULL/
>>>RESERVATION CONFLICT?
>>>
>>>I am thinking that it's the latter - i..e the interlocked UA is
>>>established only for
>>>the I_T nexus that just had a failed command - because I could not come up
>>>with
>>>a rationale for stalling all other initiators. SPC-3 however, is not
>>>explicit about it.
>>>
>>>Comments?
>>>--
>>>Mallikarjun
>>>
>>>Mallikarjun Chadalapaka
>>>Networked Storage Architecture
>>>Network Storage Solutions
>>>Hewlett-Packard MS 5668
>>>Roseville CA 95747
>>>cbm at rose.hp.com
>>>
>>>
>>Edward A. Gardner eag at ophidian.com
>>Ophidian Designs 719 593-8866 voice
>>1262 Hofstead Terrace 719 210-7200 cell
>>Colorado Springs, CO 80907
>>
>>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list