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
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