Brian:
I will agree that there are situations due
to ambiguities in when the training completed message, Sync Acquired message,
and TRAIN_DONE received messages are received that make item d necessary to
ensure that there are no implementations that fall through the crack here.
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com
From:
owner-t10@t10.org [mailto:owner-t10@t10.org] On
Behalf Of Bill.Martin@emulex.com
Sent: Wednesday, November 05, 2008
3:17 PM
To: Brian.Day@lsi.com; t10@t10.org
Subject: RE: Response to 08-425r0
Brian:
The two questions that have to be answered
are:
1) When and how is training completed generated? This is not
specified in the standard; however the next question is more pertinent to how you
guarantee reception of the TRAIN_DONE at the same time as Sync Acquired.
2) SAS2 states “When the SP_DWS receiver receives a Sync Acquired
message, it shall send the most recently received primitive.” Since it requires
three primitives to acquire sync, does this not send the TRAIN_DONE received
message along with the Sync Acquired Message?
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com
From: Day, Brian
[mailto:Brian.Day@lsi.com]
Sent: Wednesday, November 05, 2008
3:08 PM
To: Martin, Bill; t10@t10.org
Subject: RE: Response to 08-425r0
Without item d) taken into consideration,
this an example sequence I am trying to describe:
Received
Dwords DWS
state SP state
invalid
DWS0 SP29
TRAIN_DONE(3rd)
TRAIN_DONE(4th)
DWS1
TRAIN_DONE(5th)
DWS2
TRAIN_DONE(6th)
DWS3 --> SP30
(dword sync acquired here)
zero scrambled(58 times)
random scrambled "forever"
This is how I interpret the state machine
flow without the new d) item. I think where we may be seeing things
differently is based on your comment about being in SP29 for the duration of
the training pattern. My assumption was that SP transmitter enforces the
training pattern "wholeness", and perhaps your assumption is that the
SP state machine enforces the "wholeness" of the pattern. (Not I'm
kinda guessing here at where we're not together in thought)
I think I would agree with your concept of
nothing getting missed if the SP state machine only transitioned at the pattern
boundaries... but that's not how I read the wording. Am
I forgetting/missing a statement in the spec that indicates that?
Brian
From: Bill.Martin@Emulex.Com
[mailto:Bill.Martin@Emulex.Com]
Sent: Wednesday, November 05, 2008
3:43 PM
To: Day, Brian; t10@t10.org
Subject: RE: Response to 08-425r0
Brian:
The TRAIN_DONE received message is sent by
the SP Receiver to the SP state machine. The SP Receiver is responsible
for recognizing the three primitives, so this will either be seen in the SP29
or SP30 state of the SP state machine, but it will not be missed since
detecting three is not up to the SP state machine. The device will be in
the SP29 state for at least one full TRAIN or TRAIN_DONE pattern in order to
complete training. If any time during that process a TRAIN_DONE received
message is received it will set the variable that is sent to the SP30
state. I do not see any way that this message will be missed. The
previous problem was that SP29 was not looking for the TRAIN_DONE received
message, so if it was sent just before the transition to SP30 then there would
not be another one.
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com
From: Day, Brian
[mailto:Brian.Day@lsi.com]
Sent: Wednesday, November 05, 2008
2:28 PM
To: Martin, Bill; t10@t10.org
Subject: RE: Response to 08-425r0
Hi Bill...
I'm suggesting the new item d) is required
so we don't have the exact same race condition issue when the
"slower" trained device acquires dword sync on the 4th, 5th, or 6th
dword of a TRAIN_DONE (i.e. there aren't enough of the TRAIN_DONE dwords left
to detect 3 out of 6 redundant rule in the primitive sequence)
Without item d), it would be possible to
then transition to SP30 without detecting the TRAIN_DONE, and have the faster
device move to SAS_PHY_Ready, and we've got the same problem again.
Essentially, I'm suggesting a device
doesn't say TRAIN_DONE until it's reached the point where it's actually
seeing/decoding the other devices primitives, instead of just acquiring dword
sync as the gating factor.
Brian
From:
Bill.Martin@Emulex.Com [mailto:Bill.Martin@Emulex.Com]
Sent: Wednesday, November 05, 2008
12:16 PM
To: Day, Brian; t10@t10.org
Subject: Response to 08-425r0
Brian:
I understood the need to detect the TRAIN_DONE primitive in
the training state; however, I do not see the reason that a TRAIN or TRAIN_DONE
has to be received before exiting this state. The device will continue
sending TRAIN_DONE until a TRAIN_DONE is received, so the device that is later
entering the training sequence will see a TRAIN or TRAIN_DONE sequence during
its training process, and should be able to train on either pattern.
I would like to see the new item d) in 6.8.4.12.5.
I am sorry that I did not catch this part of your proposal
in our discussions on Monday.
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com