In looking at a combination of figure 35 and figure 180 in SAS2r14f, there is a potential that the first valid address frame is lost after initialization.

During training, there are no ALIGNS inserted for physical link rate tolerance matching.  This means that there can be many more dwords received than what the elasticity buffer can accommodate for a clock skew mismatch.  At the end of training, there are three identify frames sent and then a address frame may be sent.  All of these occur in less than the 512 bytes that determine when ALIGN for clock skew management shall be inserted.  The case exists where the elasticity buffer is capable of holding the three IDENTIFY address frames but then overflows during the first Address frame for a destination phy.

I do not have a proposed fix for this, but unless I have missed something, this needs to be addressed.

Bill Martin

Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com