2. The rule in the port layer is only optional if there is no I_T Nexus
Loss timer. If there is one, then Retry Open is processed as a Retry
Open. Mode pages are optional in targets, so the target might not
implement the timer. In initiators, there are no mode pages, so it's just
a "should" that the initiator implement an I_T Nexus Loss timer using the same
value as the target to which it is talking (see 8.2.2.3.1 and table 151 in
8.2.2.1).
--
Rob Elliott, elliott@hp.com
Hewlett-Packard Industry Standard Server Storage Advanced
Technology
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
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@us.ibm.com]
Sent: Wednesday, January 09, 2008 8:15
AM
To: Larry Chen
Cc: t10@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@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).