[SAS] Terminating a STP connection

Seto, Pak-lung pak-lung.seto at intel.com
Mon Jun 2 05:31:29 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Seto, Pak-lung" <pak-lung.seto at intel.com>
*
Sorry, it should be SAS v4.0 and not SATA v4.0

-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
Sent: Saturday, May 31, 2003 3:06 PM
To: t10 at t10.org
Subject: RE: [SAS] Terminating a STP connection


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*

> -----Original Message-----
> From: Seto, Pak-lung [mailto:pak-lung.seto at intel.com] 
> Sent: Friday, May 30, 2003 8:10 AM
> To: 't10 at t10.org'
> Cc: Seto, Pak-lung
> Subject: [SAS] Terminating a STP connection
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Seto, Pak-lung" <pak-lung.seto at intel.com>
> *
> SATA v4.0

I hadn't heard of that version of SATA yet :-)

> ...
> Based on 7.17.5, it looks like the only time that a STP 
> connection can be closed normally is when both sides are 
> sending and receiving SATA_SYNC.
> What happen after the STP connection is closed, the SATA 
> target sends X_RDY, X_RDY, CONT, d,d,d,d,d,d,d.  Since there is 
> no STP connection is established,
> the X_RDY will be lost when the expander re-connected to the 
> initiator.  Is the expander responsible (if it support STP) after 
> the STP connection is re-established to send
> out X_RDY, X_RDY, CONT first before pass the d,d,d,d,d,d from 
> the SATA target thru the STP path?

Yes.

> Why in 7.2.7.4, it said "Expander devices shall not transmit 
> SATA_R_RDY or SATA_X_RDY on the SATA physical link until the 
> STP connection is established"?
> The expander is not the one that is going to generate 
> SATA_R_RDY, it is just passing it thru when it received from 
> the SATA_X_RDY recipient?

Correct; it's just advising the expander not to try to reply to an 
X_RDY on its own.  If you build an expander that supports multi-
initiator ATA queuing, however, it would have to generate its own
R_RDYs and take in the frame (to figure out which initiator to
open).  The affiliation proposal removed text describing such
support, though.

> In 7.17.4 "If no STP connection exists when the SATA host port in an
> STP/SATA bridge receives a SATA_X_RDY from the attached SATA 
> device port, the STP target
> port in the STP/SATA bridge shall establish an STP connection to the
> appropriate STP initiator port before it transmits a 
> SATA_R_RDY to the SATA device."
> This is the same question as above, the STP/SATA bridge 
> should not be the one that is generating SATA_R_RDY?, it should be 
> the one that just passes the SATA_R_RDY
> received from one node to another?

Similar to the previously excerpted rule , except this is in the
context of connection management rather than primitive definition.

> In 7.17.5 the STP connection closing condition, why the SYNC 
> rece/sent state is the only time an STP connection is allowed 
> to terminate?  
> It should be able to terminate a STP connection between X_RDY 
> and SYNC?

Obviously it can't prevent closing just as the SATA device starts
sending X_RDY, but it should have had at least one dword of SYNC
each way before closing.  This rule is mainly trying to guarantee
you've reached idle after the previous activity, not that you slip
in the close immediately while both SYNCs are still on the wire.
It wouldn't hurt to ignore the new X_RDY and close the connection.

> Pak

--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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