Rev. 1 of 08-184 (adding more idle options) posted

Gerry.Houlder at Gerry.Houlder at
Tue Jun 17 07:32:58 PDT 2008

* From the T10 Reflector (t10 at, posted by:
* Gerry.Houlder at
The technical changes in this proposal (two timers added to Power Condition
mode page, log parameters added to count power condition changes, START
STOP UNIT changes to include control of the two new idle conditions) are
the same but there are a lot of wording changes in power condition model
sections as well as the indicated sections that update the wording to the
currently preferred wording of our editors. Examples of the wording changes
*  replace "activating and setting" with "enabling and initializing"
*  replace timer "reset" with "expired"
*  replace "time is zero" with time has expired"
*  replace "logical unit control" with "device server control"
*  replace one incorrect "disable" with "enable"
*  replace incorrect "and" with "or" in several places
*  combine two tables into one for easier understanding
Concepts that have been added to the power condition model include:
*  a hierarchy of power codition levels, from higher power levels to lower
power levels
*  SPC reference that warns protocol standards (e.g., SAS) may add
additional requirements
    before allowing power condition transitions (e.g, NOTIFY (ENABLE
*  require the new idle power conditions to follow existing rules for idle
power condition
The proposal adds description of allowing CHECK CONDITION status and
certain sense bytes (which have already been used in RBC for this purpose)
if an initiator requests transition to a lower power state using START STOP
UNIT command when the target knows it has a conflicting request to remain
active. One philosophy states the target should just end with GOOD status
and not transition to the lower power state (or immediately return to
active, depending on how you look at it) rather than inform the initiator
"I'm not going to do this". I intend to accept the majority opinion of the
group on this issue, so I ask folks to specifically research your company's
thoughts on this action.
These changes are incremental to existing mode pages and commands, so I
believe they are easier for systems to incorporate in the short term than
the new concepts included in proposal 08-126r1 (new MANAGE POWER IN/ OUT
commands, new INQUIRY VPD page). These new concepts may be needed but will
only have a longer term effect due to longer time needed to agree the
concepts and systems to incorporate the new concepts.
I am hoping this proposal can be voted on with only minor changes at the
July meeting. If anyone sees major issues with the proposal that might
prevent this, please comment to me and/or the reflector with your concerns.
* 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