From:
owner-t10@t10.org [mailto:owner-t10@t10.org] On
Behalf Of George Penokie
Sent: Thursday, July 06, 2006 3:44
PM
To: Larry Chen
Cc: t10@t10.org
Subject: Re: SAS error recovery
use case - Device Server detected Data Offset Error
Larry,
The
answers to your questions are as follows:
1
- Under normal operations an SSP_RESPONSE can be sent in the same connection,
but it is not possible to do that if there is a error detected at the link
layer.
[Seto] But Data Offset Error is not a link
layer error, it is a Transport Layer error, right?
That's because any of the errors
you are asking about cause the connection to be closed by the link layer. So
the answer to your specific error case in no a new connection is required to
transmit the SSP_RESPONSE.
[Seto] Don’t see why it needs a new
connection to transmit SSP_RESPONSE.
2- This cannot happen as the connection is
automatically closed when an ACK/NAK timeout occurs.
[Seto] I thought Larry’s is
questioning about – SSP_RESPONSE is received before ACK/NAK timeout?
3- Effectively yes. All the SSP state machines stop
running when either the Request Close message or the Request Break message is
sent by the SSP_D state and do not start up again until an Enable Disable SSP
message is received.
4-
The only two timers that overlap are the ACK/NAK Timeout timer and the Credit
Timeout timer. Both of those timers can cause an action by the SSP_TF2Tx_Wait
state. The description on the priority is in section 7.16.8.6.3.3 Transition
SSP_TF2:Tx_Wait to SSP_TF4:Transmit_DONE. Basically the ACK/NAK Timeout timer
has priority over the Credit Timeout timer.
The
DONE timeout timer is only relevant after a Transmitted DONE message is
received by the SSP_D state at which time no other link layer timer is relevant.
The
other link layer timers are:
The
Open Timeout timer - That timer is only used when the SL_CC state machine is in
the SL_CC!:ArbSel state. It is initialized on entry and control is completely
defined within that state.
The
Close Timeout timer - That timer is only used when the SL_CC state machine is
in the SL_CC4:DisconnectWait state. It is initialized on entry and control is
completely defined within that state.
The
Break Timeout timer - That timer is only used when the SL_CC state machine is
in the SL_CC5:BreakWait state. It is initialized on entry and control is
completely defined within that state.
Bye
for now,
George Penokie
E-Mail: gop@us.ibm.com
Internal: 553-5208
External: 507-253-5208
|
Larry Chen <Larry_Chen@pmc-sierra.com> 06/29/2006 07:07 PM |
|
Hi,
I have
an SAS error recovery use case which can not
Solve
by myself after reading the SAS-1.1 specification Rev 9e.
The
use case scenario starts when the Device Server detects
A Data
Offset Error (assume that the first of two data
Frames
is dropped/lost) during a Write command.
As
stated in the spec, the Device Server sets the appropriate
SCSI
error message in the SSP_RESPONSE frame and sends
It to
the initiator.
Ex)
Initiator
Target
---------------SSP_Command(WRITE)------------à
ß-----------------------------ACK-------------------------
ß----------------------------SSP_XFR_RDY----------
---------------------------------ACK-----------------------à
--------------SSP_DATA-1-------------à
DROPPED/LOST
--------------SSP-DATA-2------------------------------à
Data Offset Error is detected
ß------------------------------ACK-2-----------------------
ß-----------SSP_RESPONSE(DATA_OFFSET_ERROR)
QUESTION-1:
Can SSP_RESPONSE be sent in the same connection
Or
does it need to open a new connection?
QUESTION-2:
If SSP_RESPONSE is received when ACK-TOV is still
Running,
is the ACK_TOV timer supposed to be cancelled? If so, can someone
Refer
me to the place in the SAS spec where this is mentioned.
QUESTION-3:
Does closing a connection force cancelling of all
Active
timers, such as, ACK_TOV timer?
QUESTION-4:
does SAS spec mention about how ACK_TOV,
DONE_TOV,
AND BREAK_TOV timers interact e.g. priority, preemption?