[T10] [SAS]Resending Query regarding XL1 to XL5 state transition

Lana Chan lana at cadence.com
Wed May 15 15:33:53 PDT 2019


Hello,
Can you please clarify the following questions with respect to the XL state machine  - XL1 to XL5 state transition:


  1.  Per Figure K.18: Why does Expander phy (Y) not have "Arbitrating Normal confirmation" from ECM ?  Expander phy[X] has "Arbitrating Normal confirmation"
  2.  If we assume Expander Phy [X] and Expander Phy [Y] has the following state transitions:


Expander phy [X]

Expander phy [Y] -

having higher priority Add frame received

XL0: Idle

XL0: Idle

XL0: Idle -> XL1:Request_Path

XL0: Idle

XL1:Request_Path to XL2:Request_Open

XL0: Idle

XL2:Request_Open to XL3:Open_Confirm_Wait

XL0: Idle -> XL1:Request_Path



Our understanding is that if Phy[X] XL state machine is in XL3 and gives Phy Status (Partial Pathway) response to the ECM, the result is "b) Arbitrating (Wait on Partial)" confirmation for Phy[Y] XL1 state machine.  However per Section 6.19.4.4


6.19.4.4 Transition XL1:Request_Path to XL5:Forward_Open

This transition shall occur if a Forward Open indication is received and none of the following confirmations have been received:
a) Arbitrating (Normal);
b) Arbitrating (Waiting On Partial);
c) Arbitrating (Blocked On Partial);
d) Arbitrating (Waiting On Connection);
e) Arb Won;
f) Arb Lost;
g) Arb Reject (No Destination);
h) Arb Reject (Bad Destination);
i) Arb Reject (Connection Rate Not Supported);
j) Arb Reject (Zone Violation);
k) Arb Reject (Pathway Blocked); or
l) Arb Reject (Retry).





then Xl1 to XL5 state transition will never occur.  This also means that back-off reverse/retry will not occur (in XL6 state) for higher priority open address frames received from the expander Phy[Y].  Is our understanding correct?



Similarly (referencing Question (1)), if Expander phy[Y] XL state machine does have  "a) Arbitrating (Normal)" confirmation from ECM this would also block XL1 to XL5 state transition of Phy[Y]. Is this a valid interpretation?



Assuming our interpretation is valid, can we suggest the following instead:
If Request path source address argument and forward open indication destination sas address argument has same address/argument, then XL1 to XL5 state transition should not have condition a) to d) to check


Thank you in advance
Lana


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20190515/39c1efbb/attachment.html>


More information about the T10 mailing list