FC-TAPE UA conditions

Binford, Charles charles.binford at symbios.com
Wed May 6 09:34:00 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Binford, Charles" <charles.binford at symbios.com>
*

 ----------
>From: Joseph C. Nemeth
>To: T10 Reflector; T11 Reflector
>Subject: FC-TAPE UA conditions
>Date: Tuesday, May 05, 1998 4:22PM
>
>* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>* "Joseph C. Nemeth" <jnemeth at concentric.net>
>*
>According to FC-TAPE rev 1.02, section 11.5, table 20, a
>LOGO/PLOGI/PRLO/PRLI from an initiator is supposed to clear
pre-existing
>ACA, UA, and Deferred error conditions for a target with respect to
that
>initiator.

This table is directly from PLDA and I think we lost some meaning in an
attempt to make it concise for the table.  My interpretation has always
been that these events (LOGO/PLOGI...) cause the target to re-establish
any UAs it is going to report to a host the first time it talks.  For
example, suppose two initiators, I1 and  I2, are both talking to the
same target.

I1 logs in, does IO (receives Power Up UA on first IO)
I2 logs in, does IO (receives Power Up UA on first IO)
I2 sends a clear Q task management.
This causes a "Commands Cleared by another Initiator UA" to be  posted
for I1
Assume that before I1 sends another command (which would cause the UA to
be reported) I1 sends a PRLI.
The target *clears the pre-existing UA* for I1 of "Commands cleared by
another Initiator"
The target re-establishes the Power Up UA for I1, since the PRLI
effectively means this is a new initiator I've never talked to before.

Charles Binford
Symbios Inc.


>
>If the whole system powers up, and the target happens to get on the
loop
>before the initiator does, does this mean that a PON UA condition will
never
>be reported to that initiator? That doesn't seem right.
>
>On the other hand, suppose that a device powers up, and someone kicks
the FC
>cable out of the wall after about half the initiators have retrieved
and
>cleared the PON UA condition, but before the other half have accessed
the
>device. When the user plugs the cable back in, there is a huge
>LIP/LOGO/PLOGI scrum, and when it's all over, the initiators may have
all
>changed their AL_PA addresses. If *something* isn't done about the
pending
>UA conditions, some of these initiators will see the PON UA twice, and
some
>will not see it at all.
>
>It seems to me that any "new" initiator -- an initiator for which the
>[ALPA:Port:Node] triplet has changed -- should always see a PON UA
condition
>from the target, and all other UA conditions should be cleared.
>
>ACA and Deferred error conditions, on the other hand, need to be
cleared if
>the faulting initiator logs out, because they prevent other initiators
from
>accessing the device.
>
>Joseph C. Nemeth, Precision Algorithms
>
>*
>* For T10 Reflector information, send a message with
>* 'info t10' (no quotes) in the message body to majordomo at symbios.com
>
*
* 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 mailing list