I agree you have found a problem but
the solution you have given in your proposal 06-273 is not the right one.
The correct solution is to add in an item c) onto
the list which states: start the Bus
Inactivity Time Limit timer. With that then it would read:
If a Bus Inactivity Time Limit timer
has been created and:
a) the connection is SSP or SMP and
this state receives a Tx Frame message; or
b) the connection is STP and the phy
is not both transmitting and receiving SATA_SYNC,
then this state shall:
a) stop the Bus Inactivity Time Limit
timer, if it is running;
b) initialize the Bus Inactivity Time
Limit timer as specified in table 123 (see 8.2.3.1); and
c) start the Bus Inactivity
Time Limit timer.
That is all that is needed.
The change you are suggesting would
make the description of this timer different than the others and have a
ripple effect that would cause other changes throughout this section of
the standard. Also, if you look at the definition of the Bus Inactivity
Timer (see below) you will see that it is tied specifically to the frame
transmit requests not ACKs, NAKs, etc.
"The value in the BUS INACTIVITY
TIME LIMIT field contains the maximum period that an SSP target port is
permitted to maintain a connection (see 4.1.10) without transferring a
frame to the SSP initiator port. This value shall be the number of 100
ěs increments between frames that the SSP target port transmits during
a connection. When this number is exceeded, the SSP target port shall prepare
to close the connection (i.e., by requesting to have the link layer transmit
DONE). This value may be rounded as defined in SPC-3. A value of zero in
this field shall specify that there is no bus inactivity time limit. The
bus inactivity time limit is enforced by the port layer (see 8.2.3)."
Stephen FINCH <steve.finch@st.com> Sent by: owner-t10@t10.org
05/23/2006 04:14 PM
To
<t10@t10.org>
cc
Subject
SAS-2 Bus Inactivity Timer
* From the T10 Reflector (t10@t10.org), posted by:
* Stephen FINCH <steve.finch@st.com>
*
When going from SAS 1.1 to SAS 2 and incorporating changes contained per
05-305r0, we accidentally broke the Bus Inactivity Timer.
In section 8.2.3.4.1 PL_PM3:Connected state description, it states:
“If:
a) the protocol for the connection is SSP, the port is an
SSP target port, and the BUS INACTIVITY TIME LIMIT
field in the Disconnect-Reconnect mode page (see
10.2.7.1) is set to a non-zero value; or
b) the protocol for the connection is STP, the port is an
STP initiator port, and the STP BUS INACTIVITY TIME
LIMIT field is not set to zero in the SMP REPORT
GENERAL response for the destination STP target
port,
then, upon entry into this state, this state shall:
a) create a Bus Inactivity Time Limit timer;
b) initialize the Bus Inactivity Time Limit timer as specified
in table 122 (see 8.2.3.1); and
c) start the Bus Inactivity Time Limit timer.
If a Bus Inactivity Time Limit timer has been created and:
a) the connection is SSP or SMP and this state receives a
Tx Frame message; or
b) the connection is STP and the phy is not both transmitting
and receiving SATA_SYNC,
then this state shall:
a) stop the Bus Inactivity Time Limit timer, if it is running;
and
b) initialize the Bus Inactivity Time Limit timer as specified
in table 122 (see 8.2.3.1).”
My interpretation is the timer to be created when the connection is established.
When the transport requests a frame to be transmitted, the timer is stopped.
There is no case that it is again started. Thus no timeout will occur.
This is WRONG.
Proposed solution:
Add a third step to the actions to be taken after receiving a Tx Frame
message so that the
second “if” quoted above reads as follows:
“If a Bus Inactivity Time Limit timer has been created and:
a) the connection is SSP or SMP and this state receives a
Tx Frame message; or
b) the connection is STP and the phy is not both transmitting
and receiving SATA_SYNC,
then this state shall:
a) stop the Bus Inactivity Time Limit timer, if it is running;
and
b) initialize the Bus Inactivity Time Limit timer as specified
in table 122 (see 8.2.3.1).
c) start the Bus Inactivity Time Limit timer.”
Regards,
Stephen Finch
STMicroelectronics
303 381-3587
steve.finch@st.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo@t10.org