This proposal is a more significant change
as it requires an additional memory element in the state machines, a
communication mechanism between states, and changes to two of the states, as
opposed to adding an action to one existing state transition. I prefer
the change that Rob has proposed for the next revision of the SAS
specification.
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: Thursday, October 30, 2008
8:44 AM
To: Martin, Bill; t10@t10.org
Cc: Elliott@hp.com
Subject: RE: TRAIN_DONE issue
Hi all...
I have posted 08-425 as an alternative
suggested change to solve this race condition.
Brian Day
LSI Corporation.
From:
owner-t10@t10.org [mailto:owner-t10@t10.org] On
Behalf Of Bill.Martin@emulex.com
Sent: Monday, October 27, 2008
11:29 AM
To: t10@t10.org
Cc: Elliott@hp.com
Subject: TRAIN_DONE issue
There is an issue of devices not coming out of the train
done sequence properly in the following case:
Device A and Device B begin transmitting the TRAIN pattern.
Device A locks on the TRAIN pattern and begins transmitting
TRAIN_DONE
Device A completes sending 4 TRAIN_DONE patterns and
continues sending TRAIN_DONE patterns waiting for the TRAIN_DONE primitive to
be received
Device A sends TRAIN_DONE primitive sequence and one of the
dword of the TRAIN_DONE pattern
Device B completes TRAIN and sends TRAIN_DONE
Device A detects TRAIN_DONE before completing the current
TRAIN_DONE pattern and exits the TRAIN SNW (not sending any more TRAIN_DONE
primitives
Device B never detects TRAIN_DONE primitive from device A
Suggested change – device SHALL send one TRAIN_DONE
pattern after detecting TRAIN_DONE receives.
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com