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

Edward.Younk at hitachigst.com Edward.Younk at hitachigst.com
Mon Apr 25 17:30:02 PDT 2011


* From the T10 Reflector (t10 at t10.org), posted by:
* Edward.Younk at hitachigst.com
*
Hi Gerry,
Ok, I am having trouble following: 
According to
 5.9.4.10.2 Transition SP15:SAS_Phy_Ready to SP0:OOB_COMINIT
The SP state machine should transition to SP0 when a DWS_Lost message is 
received (when this state does not send a DWS_start  message)
Ok I get this, lose sync, send Cominit and try to recover the link.
Now 5.9.3.2.1 states that SP0:OOB_COMINIT  shall
d) send a Phy Layer Not Ready confirmation to the link layer. 
And according to  6.1.5.1:  a Phy Layer Not Ready message causes the 
SL_IR_IRC state machine to transition to 
SL_IR_IRC1:Idle
In this state the link layer:
b) sends a Phy Disabled confirmation to the port layer and management 
application layer indicating the phy is not ready for use.
This is the Phy Disabled message that is received by the PL_OC state 
machine, which then follows the logic I stated below.
So where am I going wrong?
If I did miss something then I have another question for you.
When you state below that the Loss of sync causes a link reset, and 
eventually a time out when the recovery fails too many times, what timer 
are you talking about? The  I_T nexus loss?  Section 4.5 I_T nexus loss 
does not say anything about the phy not being ready, only certain 
OPEN_REJECTs and open timeouts cause a I_T nexus loss.	I have hear from 
alot of people that  the I_T nexus loss timer  is the correct thing to do, 
and I also assumed this was the correct action. But then I started to dig 
into the standard trying to find support for this interpretation. I have, 
however, not found it yet:)
Edward Younk
Firmware/Hardware Engineer
Hitachi Global Storage Technologies
office: (507) 322-2116, fax: (507) 322-2400
Internet: Edward.Younk at hgst.com
Gerry Houlder <gerry.houlder at seagate.com> 
Sent by: owner-t10 at t10.org
04/25/2011 05:19 PM
To
T10 Reflector <t10 at t10.org>
cc
Subject
Re: SAS Link Reset, a down port, and I_T nexus loss
I think i can handle this one.
The Phy Disable signal is not like pulling the cable off the drive. 
Pulling the cable will cause a Loss of Sync condition, then link reset 
(recovery procedure), and eventually time out when the recovery fails too 
many times (i.e., Nexus Loss).
Phy Disable signal is like a switch on the drive that disables the phy 
without removing the cable. The drive detects this event immediately and 
therefore disables the phy immediately.
On Mon, Apr 25, 2011 at 11:21 AM, <Edward.Younk at hitachigst.com> wrote:
* 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?
--=_alternative 0002BFA78625787E_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hi Gerry,</font>
<br>
<br>
<br><font size=2 face="sans-serif">Ok, I am having trouble following:
&nbsp;</font>
<br>
<br><font size=2 face="sans-serif">According to</font>
<br>
<br><font size=2 face="sans-serif"><b>&nbsp;5.9.4.10.2 Transition
SP15:SAS_Phy_Ready
to SP0:OOB_COMINIT</b></font>
<br>
<br><font size=2 face="sans-serif"><b>The SP state machine should transition
to SP0 when a DWS_Lost message is received (when this state does not send
a DWS_start &nbsp;message)</b></font>
<br>
<br><font size=2 face="sans-serif">Ok I get this, lose sync, send Cominit
and try to recover the link.</font>
<br>
<br><font size=2 face="sans-serif"><b>Now 5.9.3.2.1 states that
SP0:OOB_COMINIT
&nbsp;shall</b></font>
<br>
<br><font size=2 face="sans-serif"><b>d) send a Phy Layer Not Ready
confirmation
to the link layer. </b></font>
<br>
<br><font size=2 face="sans-serif"><b>And according to &nbsp;6.1.5.1: &nbsp;a
Phy Layer Not Ready message causes the SL_IR_IRC state machine to transition
to </b></font>
<br><font size=2 face="sans-serif"><b>SL_IR_IRC1:Idle</b></font>
<br>
<br><font size=2 face="sans-serif">In this state the link layer:</font>
<br>
<br><font size=2 face="sans-serif"><b>b) sends a Phy Disabled confirmation
to the port layer and management &nbsp;application layer indicating the
phy is not ready for use.</b></font>
<br>
<br><font size=2 face="sans-serif">This is the Phy Disabled message that
is received by the PL_OC state machine, which then follows the logic I
stated below.</font>
<br>
<br>
<br><font size=2 face="sans-serif">So where am I going wrong?</font>
<br>
<br><font size=2 face="sans-serif">If I did miss something then I have
another question for you.</font>
<br>
<br><font size=2 face="sans-serif">When you state below that the Loss of
sync causes a link reset, and eventually a time out when the recovery fails
too many times, what timer are you talking about? The &nbsp;I_T nexus loss?
&nbsp;Section 4.5 I_T nexus loss does not say anything about the phy not
being ready, only certain OPEN_REJECTs and open timeouts cause a I_T nexus
loss. &nbsp;I have hear from alot of people that &nbsp;the I_T nexus loss
timer &nbsp;is the correct thing to do, and I also assumed this was the
correct action. But then I started to dig into the standard trying to find
support for this interpretation. I have, however, not found it yet:)</font>
<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>Gerry Houlder
<gerry.houlder at seagate.com></b>
</font>
<br><font size=1 face="sans-serif">Sent by: owner-t10 at t10.org</font>
<p><font size=1 face="sans-serif">04/25/2011 05:19 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 Reflector
<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">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><font size=3>I think i can handle this one.<br>
<br>
The Phy Disable signal is not like pulling the cable off the drive. Pulling
the cable will cause a Loss of Sync condition, then link reset (recovery
procedure), and eventually time out when the recovery fails too many times
(i.e., Nexus Loss).<br>
<br>
Phy Disable signal is like a switch on the drive that disables the phy
without removing the cable. The drive detects this event immediately and
therefore disables the phy immediately.<br>
</font>
<br><font size=3>On Mon, Apr 25, 2011 at 11:21 AM, <</font><a
href=mailto:Edward.Younk at hitachigst.com><font size=3
color=blue><u>Edward.Younk at hitachigst.com</u></font><font size=3>>
wrote:</font>
<br><font size=3>* From the T10 Reflector (</font><a
href=mailto:t10 at t10.org><font size=3
color=blue><u>t10 at t10.org</u></font><font size=3>),
posted by:<br>
* </font>Edward.Younk at hitachigst.com><font size=3
color=blue><u>Edward.Younk at hitachigst.com</u></font><font size=3><br>
*</font>
<br><font size=3>Hi George,<br>
<br>
<br>
Ok, just one more question then. Why is this an immediate nexus loss,<br>
instead starting the I_T nexus loss timer? &nbsp;It seems to me that this
event<br>
should be handled in the same manner as the I_T nexus loss cases, i.e.<br>
start the I_T nexus loss timer. &nbsp;As an example, a OPEN_REJECT(NO<br>
DESTINATION) starts the I_T nexus loss timer. &nbsp;It could've been created
by<br>
someone pulling the cable between the HBA and the expander up stream from<br>
my target. In this case we wait the I_T nexus loss timer before failing<br>
the initiator. &nbsp;In addition, if the I_T nexus loss timer is set to
0xFFFF,<br>
i.e.( the timer is disabled) we wait forever for the nexus to return.
&nbsp;If<br>
someone pulls our target's cable however, it is an immediate nexus loss?<br>
Is this really what HBA's expect?</font>
<br>
<br>
<br>
--=_alternative 0002BFA78625787E_=--
*
* 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