Announcement for Aug. 18 Interface power Management meeting

Gerry.Houlder at Gerry.Houlder at
Mon Aug 11 14:11:21 PDT 2008

* From the T10 Reflector (t10 at, posted by:
* Gerry.Houlder at
A new revision of the SAS Power Management proposal has been posted:
This revision will the the base for discussion at the Aug. 18 power
meeting ->
Other documents for discussion: 08-206, 08-249. I will not be able to
attend the meeting but Jim Hatfield (Seagate) will run the meeting in my
The agenda for this meeting will try to resolve these issues:
* Figures new1, new2, and new3 were added to 08-015r4. These depict various
normal and abnormal cases for getting into or out of partial or slumber
power conditions. Along with new text (in green), need to agree that this
is correct behavior.
* Make sure the agreed behavior for the three new figures is reflected in
correct places in the text.
* Resolve the SP state machine. 08-206 adds only 3 new states, 08-015 adds
7 new states. Two of the states in the 015 proposal (partial state and
slumber state) are combined into SP0 state by the 206 proposal; need to
decide if there are any disadvantages to doing this. The other 2 extra
states in the 015 proposal involve extra synchronization between input
signals and allowed state change; the 206 proposal synchronizes multiple
inputs before allowing state change and the 015 proposal has new state for
each single state change. Again, lets pick the correct approach.
* How/ where are the state machines changed to describe how the expander
will return AIP (WAITING ON DEVICE) to an initiator that tries to open a
target that is in partial condition or returning OPEN REJECT (RETRY) if the
target is in slumber condition. I presume this should be somewhere in the
expander state machines but please suggest where this should be described.
* Should a new OPEN REJECT primitive be created with a forced 5 or 10 ms
retry time be created? This might reduce the number of unsuccessful retries
(e.g., OPEN frame, OPEN REJECT (RETRY) response, repeat quickly) that could
occur during slumber recovery. Disadvantage: older hosts with newer
expander/target might not understand the new primitive and would treat it
same as OPEN REJECT (RETRY) anyway.
* I have an issue with consequences to an expander if (1) target and
expander agree on partial condition; (2) target is hot-plugged; (3)
initiator tries to open the target; (4) how long of a "hot-plug timeout"
can the expander tolerate before recognizing the target is gone and
changing to a different response [e.g., OPEN REJECT (NO DESTINATION)]. It
has been suggested that a regular hot-plug timeout interval (500 msec) be
used for this but this is too long to respond with AIP (WAITING ON DEVICE)
and might also be too long for OPEN REJECT (RETRY). Since the expander has
two different responses (depending on whether partial or slumber is
expected) perhaps there should be two different timeouts [e.g., 20 us and
20 ms respectively] that are more in tune with the responses the expander
has to generate?
* What primitive encodings should be chosen for the four new primitives I
random codings from the list of "reserved for future use" codes or is there
a better way?
* The proposal currently suggests ALIGN(0) and ALIGN(1) as the
synchronization primitives in the PM recovery sequence. There was a
suggestion in an earlier teleconference that a different pair of ALIGN
primitives might be a better choice. Lets decide this.
* The AIP (WAITING ON DEVICE) primitive has a "can only be sent one time"
restriction on it and is only effective for 1 ms. Should the restriction be
lifted so multiple AIPs can be sent? Decision has bearing on timeout
interval for recovery from partial power condition.
* Does SATA interface power management for STP links need to be prohibited
if SAS power management for SSP links is supported?
* What additional description should be added to section 7.10 for power
* Should targets be allowed to automatically change from partial to slumber
power condition? I say no, because the expander has to know the target
state so that appropriate initiator response to OPEN frame is made. If we
made the expander response the same for both cases, perhaps this feature
could be allowed. Any advantages/ disadvantage to this?
* The link layer state machine changes (08-249) needs discussion.
* Do any higher (than link layer) state machines need to be involved in any
of the error cases? There may need to be new messages or responses created
to handle this, or just algorithms.
* Any other subjects that meeting attendees wish to discuss?
I hope everyone attending will have an opportunity to form their opinion on
these issues before Aug. 18 so it is quicker to make progress.
If all of these items get resolved and there is still meeting time left
(this is unlikely), the group may discuss proposal 08-184r2 (Adding more
low power options), which should be posted before Aug. 15.
* 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