FC-TAPE UA conditions
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
>ACA, UA, and Deferred error conditions for a target with respect to
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
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
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
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.
>If the whole system powers up, and the target happens to get on the
>before the initiator does, does this mean that a PON UA condition will
>be reported to that initiator? That doesn't seem right.
>On the other hand, suppose that a device powers up, and someone kicks
>cable out of the wall after about half the initiators have retrieved
>cleared the PON UA condition, but before the other half have accessed
>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
>changed their AL_PA addresses. If *something* isn't done about the
>UA conditions, some of these initiators will see the PON UA twice, and
>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
>from the target, and all other UA conditions should be cleared.
>ACA and Deferred error conditions, on the other hand, need to be
>the faulting initiator logs out, because they prevent other initiators
>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