[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