To: "Larry Chen" <Larry_Chen@pmc-sierra.com>
Cc: t10@t10.org
Subject: Re: SAS2 - OPEN TIMEOUT
From: Kevin D Butt <kdbutt@us.ibm.com>
Date: Wed, 9 Jan 2008 09:14:47 -0700
X-Message-Number: 8432
Formatted message: HTML-formatted message

 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@us.ibm.com
http://www-03.ibm.com/servers/storage/ 
"Larry Chen" <Larry_Chen@pmc-sierra.com> 
Sent by: owner-t10@t10.org
01/08/2008 03:00 PM
To
<t10@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).