SAS2 - OPEN TIMEOUT

Sheffield, Bob Bob.Sheffield at lsi.com
Wed Jan 9 15:35:22 PST 2008


Formatted message: <A HREF="r0801095_f.htm">HTML-formatted message</A>

This discussion raises a more basic question for me: does the term,
"open connection timeout" mean the same thing as "Connection Timeout
Timer expires"? The term, "open connection timeout" occurs only once in
the entire standard (in subclause 4.5), whereas the term "Open Timeout
Timer expires" occurs 7 times in the text. The latter is what happens
when the attached phy doesn't send an ARB for 1ms. There is a
corresponding confirmation from the link layer to the port layer, "Open
Timeout Occurred", which sounds a lot like "open connection timeout",
but is not explicitly equivalent.
Subclause 8.2.2.3.2 PL_OC2:Overall_Control state establishing
connections states:
	If this state receives a Retry Open (No Destination) or a Retry
Open (Open
	Timeout Occurred) message and an I_T Nexus Loss timer has not
been created for
	the destination SAS address (e.g., an SSP target port does not
support the I_T
	NEXUS LOSS TIME field in the Protocol-Specific Port mode page or
the field is
	set to 0000h), then this state shall process the Retry Open
message as either a
	Retry Open message or an Unable To Connect message. This
selection is
	vendor-specific.
Indicating it may be optional whether to retry or not. This behavior is
at the port level, so it applies not only to initiator ports, but also
to target ports and expander ports. I could see different port types
needing to handle this differently.
Incidently, a self-configuring expander has a way to report this
condition to a management application, "Connection request failed: Open
Timeout timer expired" (see table 235 in subclause 10.4.3.5.4
Self-configuration status descriptor).
Bob Sheffield
LSI Corporation
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Larry
Chen
Sent: Wednesday, January 09, 2008 2:35 PM
To: Kevin D Butt
Cc: t10 at t10.org
Subject: RE: SAS2 - OPEN TIMEOUT
IMO, Timeouts are more serious than OPEN_REJECTs (and NAK, SCSI Busy and
Full Queue) Responses.
If Timeouts are _not_ reported to the host driver and/or the diagnostic
monitoring code then the problem can not
be detected and rectified Via a FRU swap.
________________________________
From: Kevin D Butt [mailto:kdbutt at us.ibm.com] 
Sent: Wednesday, January 09, 2008 8:15 AM
To: Larry Chen
Cc: t10 at t10.org
Subject: Re: SAS2 - OPEN TIMEOUT
 I do not see a reason to distinguish an open timeout from the other
errors.  Unless there is a very good reason, I would prefer to leave the
text as is.  It seems to me that we should retry open timeouts, since it
may work the next time.  Also, the point of doing recovery operations is
to mask errors (so that the job can continue), so that does not seem
like a good reason to stop attempting the recovery.   
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Larry Chen" <Larry_Chen at pmc-sierra.com> 
Sent by: owner-t10 at t10.org 
01/08/2008 03:00 PM 
To
<t10 at t10.org> 
cc
Subject
SAS2 - OPEN TIMEOUT
Is there any mechanism in place to _exclude_ OPEN TIMEOUT from being
retried (see 
RED font below for details). I think there is a danger of masking out
errors if OPEN TIMEOUT 
Is blindly retried. 
--- 
4.5 I_T nexus loss 
When a SAS port receives OPEN_REJECT (NO DESTINATION), OPEN_REJECT
(PATHWAY BLOCKED), 
OPEN_REJECT (RESERVED INITIALIZE 0), OPEN_REJECT (RESERVED INITIALIZE
1), OPEN_REJECT 
(RESERVED STOP 0), OPEN_REJECT (RESERVED STOP 1), or an open connection
timeout occurs in 
response to a connection request, it shall retry the connection request
until: 
a) the connection is established; 
b) for SSP target ports, the time indicated by the I_T NEXUS LOSS TIME
field in the Protocol-Specific Port 
mode page (see 10.2.7.4) expires; or 
c) the I_T nexus loss timer, if any, expires (see 4.7.1, 8.2.2.1,
10.2.7.4, and 10.4.3.17). 



More information about the T10 mailing list