SAS Link Reset, a down port, and I_T nexus loss

Edward.Younk at hitachigst.com Edward.Younk at hitachigst.com
Mon Apr 25 09:21:57 PDT 2011


* From the T10 Reflector (t10 at t10.org), posted by:
* Edward.Younk at hitachigst.com
*
Hi George,
Ok, just one more question then. Why is this an immediate nexus loss,
instead starting the I_T nexus loss timer?  It seems to me that this event
should be handled in the same manner as the I_T nexus loss cases, i.e.
start the I_T nexus loss timer.  As an example, a OPEN_REJECT(NO
DESTINATION) starts the I_T nexus loss timer.  It could've been created by
someone pulling the cable between the HBA and the expander up stream from
my target. In this case we wait the I_T nexus loss timer before failing
the initiator.	In addition, if the I_T nexus loss timer is set to 0xFFFF,
i.e.( the timer is disabled) we wait forever for the nexus to return.  If
someone pulls our target's cable however, it is an immediate nexus loss?
Is this really what HBA's expect?
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
"Penokie, George" <George.Penokie at lsi.com>
04/25/2011 10:01 AM
To
"Edward.Younk at hitachigst.com" <Edward.Younk at hitachigst.com>
cc
Subject
RE: SAS Link Reset, a down port, and I_T nexus loss
Ed,
Yes,
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Edward.Younk at hitachigst.com
Sent: Sunday, April 24, 2011 8:13 PM
To: t10 at t10.org
Subject: Fw: SAS Link Reset, a down port, and I_T nexus loss
* From the T10 Reflector (t10 at t10.org), posted by:
* Edward.Younk at hitachigst.com
*
Hi everyone,
This is a resend, since I haven't see this get out on the reflector yet.
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
----- Forwarded by Edward Younk/US/HGST on 04/24/2011 08:11 PM -----
Edward Younk/US/HGST
04/22/2011 05:05 PM
To
t10 at t10.org
cc
Subject
Fw: SAS Link Reset, a down port, and I_T nexus loss
Hi everyone,
I think I found the answer to my question.
The PL_OC1:Idle state machine handles the case where a port has no enabled
phys.  If our target consists of two ports of one phy each, then the phy
being disabled would cause us to go from the PL_OC2:Overall Control state
to the PL_OC1:Idle state. In this state, if a Transmit frame message is
received by the transport layer, the PL_OC state machine should respond
with a "no phys in port" message to the transport layer.
Up is the ST_TFR state machine, a "no phys in port" message should
generate a "nexus loss" message to the application layer.
Therefore, in the case I described below, I think the correct answer is to
declare a  nexus loss as soon as we detect the phy go down, and we need to
send a frame to the initiator. Am I reading this right?
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
----- Forwarded by Edward Younk/US/HGST on 04/22/2011 04:50 PM -----
Edward Younk/US/HGST
04/22/2011 11:10 AM
To
t10 at t10.org
cc
Subject
SAS Link Reset, a down port, and I_T nexus loss
Hi SAS guys,
I have a question that I hope one of you can answer.  Section 4.4.1 of
spl07 states: "The link reset sequence has no effect on the transport
layer and application layer unless the link reset sequence disrupts frame
transmission. "
 In addition, section 4.5 describes the conditions which cause the I_T
nexus loss timer to run.  They include:
Open reject (No destination, Pathway blocked, reserved initialized 0, 1,
reservered stop 0, 1) or a Open timeout.
I feel that a down link should also  start this timer, but I can't find
anything in the standard to justify this interpretation.
Consider the following scenario with a multiple initiator dual port SAS
target environment.
Commands being executed on both ports of the target by multiple
initiators.
1. Write command received on port A.
2. Target asks for data from the initiator, receives all the data, and
proceeds to write the data to the media.
3. The link on port A goes down for whatever reason. (Frame transmission
for the write was not disrupted.)
4. The target finishes the write, and prepares to send status.	However,
the port is now down and a link reset sequence is being run to recover the
link.
So here's the question, how long should the target wait for the link to
come back up, before giving up trying to send status for the write
command. In addition, how long should the target hang on to commands for
the initiators communicating through that port.  If the target implements
a unified queue for all initiators, the initiators on port B could be
waiting a long time for their commands to execute.  It seems that the only
way out of this would be for the initiators on port B to hit that port
with an abort queue or hard reset, in order to clean the queue of commands
|from initiators who were talking on port A.
It seems to me that a down port should be handled in the same manner as
Open reject(No destination) i.e., start the I_T nexus loss timer.  Am  I
right, or am I wrong?  Please enlighten me.
Thanks for the help.
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
--=_alternative 0006A71D8625787D_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hi everyone,</font>
<br>
<br>
<br><font size=2 face="sans-serif">This is a resend, since I haven't see
this get out on the reflector yet.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Edward
Younk/US/HGST on 04/24/2011 08:11 PM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Edward Younk/US/HGST</b>
</font>
<p><font size=1 face="sans-serif">04/22/2011 05:05 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">t10 at t10.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Fw: SAS Link Reset, a down
port, and I_T nexus loss</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br><font size=2 face="sans-serif">Hi everyone,</font>
<br>
<br><font size=2 face="sans-serif">I think I found the answer to my
question.</font>
<br>
<br><font size=2 face="sans-serif">The PL_OC1:Idle state machine handles
the case where a port has no enabled phys. &nbsp;If our target consists
of two ports of one phy each, then the phy being disabled would cause us
to go from the PL_OC2:Overall Control state to the PL_OC1:Idle state. In
this state, if a Transmit frame message is received by the transport
layer,
the PL_OC state machine should respond with a "no phys in port"
message to the transport layer.</font>
<br>
<br><font size=2 face="sans-serif">Up is the ST_TFR state machine, a
"no
phys in port" message should generate a "nexus loss"
message
to the application layer. &nbsp;</font>
<br>
<br>
<br><font size=2 face="sans-serif">Therefore, in the case I described
below,
I think the correct answer is to declare a &nbsp;nexus loss as soon as
we detect the phy go down, and we need to send a frame to the initiator.
Am I reading this right?</font>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Edward
Younk/US/HGST on 04/22/2011 04:50 PM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Edward Younk/US/HGST</b>
</font>
<p><font size=1 face="sans-serif">04/22/2011 11:10 AM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">t10 at t10.org</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">SAS Link Reset, a down port,
and I_T nexus loss</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Hi SAS guys,</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">I have a question that I hope one of
you can answer. &nbsp;Section 4.4.1 of spl07 states: "The link reset
sequence has no effect on the transport layer and application layer unless
the link reset sequence disrupts frame transmission. " </font>
<br>
<br><font size=2 face="sans-serif">&nbsp;In addition, section 4.5
describes
the conditions which cause the I_T nexus loss timer to run. &nbsp;They
include:</font>
<br><font size=2 face="sans-serif">Open reject (No destination, Pathway
blocked, reserved initialized 0, 1, reservered stop 0, 1) or a Open
timeout.
</font>
<br>
<br><font size=2 face="sans-serif">I feel that a down link should also
&nbsp;start this timer, but I can't find anything in the standard to
justify
this interpretation.</font>
<br>
<br><font size=2 face="sans-serif">Consider the following scenario with
a multiple initiator dual port SAS target environment.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Commands being executed on both ports
of the target by multiple initiators.</font>
<br>
<br><font size=2 face="sans-serif">1. Write command received on port
A.</font>
<br><font size=2 face="sans-serif">2. Target asks for data from the
initiator,
receives all the data, and proceeds to write the data to the media.</font>
<br><font size=2 face="sans-serif">3. The link on port A goes down for
whatever reason. (Frame transmission for the write was not
disrupted.)</font>
<br><font size=2 face="sans-serif">4. The target finishes the write, and
prepares to send status. &nbsp;However, the port is now down and a link
reset sequence is being run to recover the link.</font>
<br>
<br><font size=2 face="sans-serif">So here's the question, how long should
the target wait for the link to come back up, before giving up trying to
send status for the write command. In addition, how long should the target
hang on to commands for the initiators communicating through that port.
&nbsp;If the target implements a unified queue for all initiators, the
initiators on port B could be waiting a long time for their commands to
execute. &nbsp;It seems that the only way out of this would be for the
initiators on port B to hit that port with an abort queue or hard reset,
in order to clean the queue of commands from initiators who were talking
on port A.</font>
<br>
<br><font size=2 face="sans-serif">It seems to me that a down port should
be handled in the same manner as Open reject(No destination) i.e., start
the I_T nexus loss timer. &nbsp;Am &nbsp;I right, or am I wrong?
&nbsp;Please
enlighten me. &nbsp;</font>
<br>
<br>
<br><font size=2 face="sans-serif">Thanks for the help.</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
</font>
--=_alternative 0006A71D8625787D_=--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
--=_alternative 0059E62B8625787D_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hi George,</font>
<br>
<br>
<br><font size=2 face="sans-serif">Ok, just one more question then. Why
is this an immediate nexus loss, instead starting the I_T nexus loss timer?
&nbsp;It seems to me that this event should be handled in the same manner
as the I_T nexus loss cases, i.e. start the I_T nexus loss timer. &nbsp;As
an example, a OPEN_REJECT(NO DESTINATION) starts the I_T nexus loss timer.
&nbsp;It could've been created by someone pulling the cable between the
HBA and the expander up stream from my target. In this case we wait the
I_T nexus loss timer before failing the initiator. &nbsp;In addition, if
the I_T nexus loss timer is set to 0xFFFF, i.e.( the timer is disabled)
we wait forever for the nexus to return. &nbsp;If someone pulls our target's
cable however, it is an immediate nexus loss? Is this really what HBA's
expect?</font>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Penokie, George"
<George.Penokie at lsi.com></b> </font>
<p><font size=1 face="sans-serif">04/25/2011 10:01 AM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1
face="sans-serif">"Edward.Younk at hitachigst.com"
<Edward.Younk at hitachigst.com></font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: SAS Link Reset, a down
port, and I_T nexus loss</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Ed,<br>
<br>
Yes, <br>
<br>
Bye for now, <br>
George Penokie<br>
 <br>
LSI Corporation <br>
3033 41st St. NW <br>
Suite 100 <br>
Rochester, MN 55901<br>
 <br>
507-328-9017 <br>
george.penokie at lsi.com<br>
<br>
<br>
-----Original Message-----<br>
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Edward.Younk at hitachigst.com<br>
Sent: Sunday, April 24, 2011 8:13 PM<br>
To: t10 at t10.org<br>
Subject: Fw: SAS Link Reset, a down port, and I_T nexus loss<br>
<br>
* From the T10 Reflector (t10 at t10.org), posted by:<br>
* Edward.Younk at hitachigst.com<br>
*<br>
Hi everyone,<br>
<br>
<br>
This is a resend, since I haven't see this get out on the reflector yet.<br>
<br>
<br>
Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
<br>
----- Forwarded by Edward Younk/US/HGST on 04/24/2011 08:11 PM -----<br>
<br>
Edward Younk/US/HGST <br>
04/22/2011 05:05 PM<br>
<br>
To<br>
t10 at t10.org<br>
cc<br>
<br>
Subject<br>
Fw: SAS Link Reset, a down port, and I_T nexus loss<br>
<br>
<br>
<br>
<br>
<br>
Hi everyone,<br>
<br>
I think I found the answer to my question.<br>
<br>
The PL_OC1:Idle state machine handles the case where a port has no enabled
<br>
phys. &nbsp;If our target consists of two ports of one phy each, then the
phy <br>
being disabled would cause us to go from the PL_OC2:Overall Control state
<br>
to the PL_OC1:Idle state. In this state, if a Transmit frame message is
<br>
received by the transport layer, the PL_OC state machine should respond
<br>
with a "no phys in port" message to the transport layer.<br>
<br>
Up is the ST_TFR state machine, a "no phys in port" message should
<br>
generate a "nexus loss" message to the application layer. <br>
<br>
<br>
Therefore, in the case I described below, I think the correct answer is
to <br>
declare a &nbsp;nexus loss as soon as we detect the phy go down, and we
need to <br>
send a frame to the initiator. Am I reading this right?<br>
<br>
<br>
<br>
<br>
Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
<br>
----- Forwarded by Edward Younk/US/HGST on 04/22/2011 04:50 PM -----<br>
<br>
Edward Younk/US/HGST <br>
04/22/2011 11:10 AM<br>
<br>
To<br>
t10 at t10.org<br>
cc<br>
<br>
Subject<br>
SAS Link Reset, a down port, and I_T nexus loss<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Hi SAS guys,<br>
<br>
<br>
<br>
I have a question that I hope one of you can answer. &nbsp;Section 4.4.1
of <br>
spl07 states: "The link reset sequence has no effect on the transport
<br>
layer and application layer unless the link reset sequence disrupts frame
<br>
transmission. " <br>
<br>
 In addition, section 4.5 describes the conditions which cause the I_T
<br>
nexus loss timer to run. &nbsp;They include:<br>
Open reject (No destination, Pathway blocked, reserved initialized 0, 1,
<br>
reservered stop 0, 1) or a Open timeout. <br>
<br>
I feel that a down link should also &nbsp;start this timer, but I can't
find <br>
anything in the standard to justify this interpretation.<br>
<br>
Consider the following scenario with a multiple initiator dual port SAS
<br>
target environment.<br>
<br>
<br>
Commands being executed on both ports of the target by multiple <br>
initiators.<br>
<br>
1. Write command received on port A.<br>
2. Target asks for data from the initiator, receives all the data, and
<br>
proceeds to write the data to the media.<br>
3. The link on port A goes down for whatever reason. (Frame transmission
<br>
for the write was not disrupted.)<br>
4. The target finishes the write, and prepares to send status. &nbsp;However,
<br>
the port is now down and a link reset sequence is being run to recover
the <br>
link.<br>
<br>
So here's the question, how long should the target wait for the link to
<br>
come back up, before giving up trying to send status for the write <br>
command. In addition, how long should the target hang on to commands for
<br>
the initiators communicating through that port. &nbsp;If the target
implements
<br>
a unified queue for all initiators, the initiators on port B could be <br>
waiting a long time for their commands to execute. &nbsp;It seems that
the only <br>
way out of this would be for the initiators on port B to hit that port
<br>
with an abort queue or hard reset, in order to clean the queue of commands
<br>
|from initiators who were talking on port A.<br>
<br>
It seems to me that a down port should be handled in the same manner as
<br>
Open reject(No destination) i.e., start the I_T nexus loss timer. &nbsp;Am
&nbsp;I <br>
right, or am I wrong? &nbsp;Please enlighten me. <br>
<br>
<br>
Thanks for the help.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Edward Younk<br>
Firmware/Hardware Engineer<br>
Hitachi Global Storage Technologies<br>
office: (507) 322-2116, fax: (507) 322-2400<br>
Internet: Edward.Younk at hgst.com<br>
<br>
--=_alternative 0006A71D8625787D_=<br>
Content-Type: text/html; charset="US-ASCII"<br>
<br>
<br>
<br><font size=2 face="sans-serif">Hi
everyone,</font><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">This is a resend,
since I haven't see<br>
this get out on the reflector yet.</font><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">Edward
Younk<br><br>
Firmware/Hardware Engineer<br><br>
Hitachi Global Storage Technologies<br><br>
office: (507) 322-2116, fax: (507) 322-2400<br><br>
Internet: Edward.Younk at hgst.com<br><br>
</font><br>
<br><font size=1 color=#800080 face="sans-serif">-----
Forwarded by Edward<br>
Younk/US/HGST on 04/24/2011 08:11 PM -----</font><br>
<br><br>
<table width=100%><br>
<tr valign=top><br>
<td width=40%><font size=1
face="sans-serif"><b>Edward
Younk/US/HGST</b><br>
</font><br>
<p><font size=1 face="sans-serif">04/22/2011 05:05
PM</font><br>
<td width=59%><br>
<table width=100%><br>
<tr><br>
<td><br>
<div align=right><font size=1
face="sans-serif">To</font></div><br>
<td valign=top><font size=1
face="sans-serif">t10 at t10.org</font><br>
<tr><br>
<td><br>
<div align=right><font size=1
face="sans-serif">cc</font></div><br>
<td valign=top><br>
<tr><br>
<td><br>
<div align=right><font size=1
face="sans-serif">Subject</font></div><br>
<td valign=top><font size=1 face="sans-serif">Fw:
SAS Link Reset, a down<br>
port, and I_T nexus loss</font></table><br>
<br><br>
<table><br>
<tr valign=top><br>
<td><br>
<td></table><br>
<br></table><br>
<br><br>
<br><font size=2 face="sans-serif">Hi
everyone,</font><br>
<br><br>
<br><font size=2 face="sans-serif">I think I found
the answer to my question.</font><br>
<br><br>
<br><font size=2 face="sans-serif">The PL_OC1:Idle
state machine handles<br>
the case where a port has no enabled phys. &nbsp;If our target
consists<br>
of two ports of one phy each, then the phy being disabled would cause us<br>
to go from the PL_OC2:Overall Control state to the PL_OC1:Idle state. In<br>
this state, if a Transmit frame message is received by the transport
layer,<br>
the PL_OC state machine should respond with a "no phys in
port"<br>
message to the transport layer.</font><br>
<br><br>
<br><font size=2 face="sans-serif">Up is the ST_TFR
state machine, a "no<br>
phys in port" message should generate a "nexus
loss"
message<br>
to the application layer. &nbsp;</font><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">Therefore, in
the case I described below,<br>
I think the correct answer is to declare a &nbsp;nexus loss as soon
as<br>
we detect the phy go down, and we need to send a frame to the initiator.<br>
Am I reading this right?</font><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">Edward
Younk<br><br>
Firmware/Hardware Engineer<br><br>
Hitachi Global Storage Technologies<br><br>
office: (507) 322-2116, fax: (507) 322-2400<br><br>
Internet: Edward.Younk at hgst.com<br><br>
</font><br>
<br><font size=1 color=#800080 face="sans-serif">-----
Forwarded by Edward<br>
Younk/US/HGST on 04/22/2011 04:50 PM -----</font><br>
<br><br>
<table width=100%><br>
<tr valign=top><br>
<td width=40%><font size=1
face="sans-serif"><b>Edward
Younk/US/HGST</b><br>
</font><br>
<p><font size=1 face="sans-serif">04/22/2011 11:10
AM</font><br>
<td width=59%><br>
<table width=100%><br>
<tr><br>
<td><br>
<div align=right><font size=1
face="sans-serif">To</font></div><br>
<td valign=top><font size=1
face="sans-serif">t10 at t10.org</font><br>
<tr><br>
<td><br>
<div align=right><font size=1
face="sans-serif">cc</font></div><br>
<td valign=top><br>
<tr><br>
<td><br>
<div align=right><font size=1
face="sans-serif">Subject</font></div><br>
<td valign=top><font size=1 face="sans-serif">SAS
Link Reset, a down port,<br>
and I_T nexus loss</font></table><br>
<br><br>
<table><br>
<tr valign=top><br>
<td><br>
<td></table><br>
<br></table><br>
<br><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">Hi SAS
guys,</font><br>
<br><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">I have a question
that I hope one of<br>
you can answer. &nbsp;Section 4.4.1 of spl07 states: "The
link reset<br>
sequence has no effect on the transport layer and application layer
unless<br>
the link reset sequence disrupts frame transmission. "
</font><br>
<br><br>
<br><font size=2 face="sans-serif">&nbsp;In
addition,
section 4.5 describes<br>
the conditions which cause the I_T nexus loss timer to run.
&nbsp;They<br>
include:</font><br>
<br><font size=2 face="sans-serif">Open reject (No
destination, Pathway<br>
blocked, reserved initialized 0, 1, reservered stop 0, 1) or a Open
timeout.<br>
</font><br>
<br><br>
<br><font size=2 face="sans-serif">I feel that a
down link should also<br>
&nbsp;start this timer, but I can't find anything in the standard to
justify<br>
this interpretation.</font><br>
<br><br>
<br><font size=2 face="sans-serif">Consider the
following
scenario with<br>
a multiple initiator dual port SAS target environment.</font><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">Commands being
executed on both ports<br>
of the target by multiple initiators.</font><br>
<br><br>
<br><font size=2 face="sans-serif">1. Write command
received on port A.</font><br>
<br><font size=2 face="sans-serif">2. Target asks
for data from the initiator,<br>
receives all the data, and proceeds to write the data to the
media.</font><br>
<br><font size=2 face="sans-serif">3. The link on
port A goes down for<br>
whatever reason. (Frame transmission for the write was not
disrupted.)</font><br>
<br><font size=2 face="sans-serif">4. The target
finishes the write, and<br>
prepares to send status. &nbsp;However, the port is now down and a
link<br>
reset sequence is being run to recover the link.</font><br>
<br><br>
<br><font size=2 face="sans-serif">So here's the
question, how long should<br>
the target wait for the link to come back up, before giving up trying to<br>
send status for the write command. In addition, how long should the
target<br>
hang on to commands for the initiators communicating through that port.<br>
&nbsp;If the target implements a unified queue for all initiators,
the<br>
initiators on port B could be waiting a long time for their commands to<br>
execute. &nbsp;It seems that the only way out of this would be for
the<br>
initiators on port B to hit that port with an abort queue or hard reset,<br>
in order to clean the queue of commands from initiators who were talking<br>
on port A.</font><br>
<br><br>
<br><font size=2 face="sans-serif">It seems to me
that a down port should<br>
be handled in the same manner as Open reject(No destination) i.e., start<br>
the I_T nexus loss timer. &nbsp;Am &nbsp;I right, or am I wrong?
&nbsp;Please<br>
enlighten me. &nbsp;</font><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">Thanks for the
help.</font><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br><font size=2 face="sans-serif">Edward
Younk<br><br>
Firmware/Hardware Engineer<br><br>
Hitachi Global Storage Technologies<br><br>
office: (507) 322-2116, fax: (507) 322-2400<br><br>
Internet: Edward.Younk at hgst.com<br><br>
</font><br>
--=_alternative 0006A71D8625787D_=--<br>
<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org<br>
</font></tt>
<br>
--=_alternative 0059E62B8625787D_=--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list