SAS SL_CC handling of CLOSE

Day, Brian bday at
Wed Apr 2 15:09:51 PST 2003

* From the T10 Reflector (t10 at, posted by:
* "Day, Brian" <bday at>

I don't think there is any "clean-up" required when the STP/SATA bridge
piece closes the connection just as the SATA device wants to send a frame.
Based on the CLOSE rules for STP connection that were added in my 02-363, as
long as the bridge hasn't given any hint that the SATA device wants to send
a frame over the STP connection (as determined that is hasn't forwarded the
X_RDY from the SATA link to the STP link), then there aren't any frames that
get corrupted or lost.

In this case, the STP/SATA bridge would just continue to send SATA_SYNCs to
the SATA device, until the connection to the initiator is re-established at
some later (perhaps MUCH later) time.

Brian Day
LSI Logic

-----Original Message-----
From: Sheffield, Robert L [mailto:robert.l.sheffield at]
Sent: Wednesday, April 02, 2003 2:40 PM
To: George Penokie; Elliott, Robert (Server Storage)
Cc: owner-t10 at; t10 at
Subject: RE: SAS SL_CC handling of CLOSE

* From the T10 Reflector (t10 at, posted by:
* "Sheffield, Robert L" <robert.l.sheffield at>
Let's see first if I can restate the problem to make sure I'm clear on it...

The STP/SATA bridge is responsible for deciding when to request a close on
behalf of a SATA device. The SATA device knows whether it has frames to
send, but the bridge doesn't, and there doesn't seem to be a reliable way
for the SATA device to inform the bridge whether or not it will have frames
to send. So whatever heuristics the bridge uses to decide when to send a
close, there's a race condition where the SATA device attempts to send
frames just as the bridge decides to close the connection. I'm not sure what
we can do about that.

If we simply accept that this race condition occurs and requires cleanup of
some kind (close connection, reset device, retry command???) then perhaps
there's a more straightforward solution:
1. Prohibit STP target ports (or perhaps just SATA/STP bridges) from
generating CLOSE.
2. Require STP target ports to close immediately upon receipt of CLOSE
without requiring a preceding Request Close from the Link Layer.

This leaves it entirely up to the STP initiator port to manage closing
connections. Since an STP/SATA bridge doesn't ever generate CLOSE, the STP
initiator port doesn't ever have to worry about receiving a CLOSE without
first having received a Request Close from the link layer. The race
condition at the STP/SATA bridge still exists, but the STP initiator sees
all of the traffic from the SATA target just like the STP/SATA bridge, so it
has at least as much information to work with as the STP/SATA bridge, plus
some concept of the state of execution of outstanding commands, so it ought
to be able to do as good a job of deciding when to close the connection as
the bridge could.

This just applies to SATA devices attached through an STP/SATA bridge. We
might want STP target devices to behave differently since they can account
for the internal state of command execution in deciding when to close

This isn't a formal proposal to resolve the problem, just some thoughts.
What do you think?


Bob Sheffield
Intel Corporation - CH6-333
Storage Components Division (SCD)
5000 W. Chandler Blvd
Chandler, AZ 85226-3699
Phone: 480-554-8597
Fax: 480-554-6617

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list