[T10] Let's talk Power Condition Timers

[Ralph Weber]

First a word of thanks for the T10 website. This research would have been impossible without the T10 website. SBC r00 was downloaded from November 1994, as was X3T9.2/91-014r6. The latter document is so old that a special URL is needed to obtain it: http://www.t10.org/ftp/x3t9.2/document.91/91-014r6.txt and yes the 91-014 is only available as text file. They really did use stone knives and bear skins back in those days.

Another nifty webpage for SCSI Archeologists is https://www.t10.org/members/w_status.htm, where...

  *   the left column names standards and provides links to their last/latest revisions; and
  *   the right column contains links to tables of all revisions, complete with names, dates, sizes, and download links

Those wishing to check the bevy of moldy-oldy working drafts mentioned below will find the link above indispensable.

History lesson - in the beginning

When it comes to the bowels of SCSI, I long ago learned to be wary of questioning Gerry Houlder's gut instincts.

Gerry's pronouncement was spot-on; the ACTIVE, IDLE, and STANDBY Power Condition codepoints are clearly spec'd to put the drive in a mode where the host controls dominate (i.e., the power condition timers are veritable NOPs). Furthermore, this situation has existed since February 1995 when 91-014r6 was incorporated into SBC r01 (fully five years before the earliest date when SBC-2 et al. were in anybody's bookmarks).

Gerry's description of Power Condition codepoint 7 also hit the nail on the head. He even remembered almost word-for-word the way 91-014r6 describes codepoint 7, "Give control of power conditions to logical unit".

You may ask, why there was/is no clear description of the *real* relationship between codepoint 7 and codepoints 1, 2, and 3? Because in 1991, nobody was disposed to raise such issues. The definitions of the codepoints were thought to be clear in-and-of themselves.

Nonetheless, the major factors that had CAP tied in knots last Tuesday have been in SBC for solidly a quarter century, although they started life as a paragraph after the table instead of a footnote in the table. (Table footnotes did not come into vogue until early 2009, circa the posting of SBC-3 r17.)

History lesson - in the muddled middle

This is where the sands of time have not been kind to Gerry (or the rest of us, for that matter).

The text in the table footnote that had CAP chasing its tail, didn't always read like it does in SBC-5 r01. In 1991, the .txt file read, "... -suspend any Power Condition timers ... that are active on receipt of the Start/Stop Command until another Start/Stop Command is received which returns control of the power condition to the logical unit or a hard reset occurs."

Between the posting of SBC r10 in 1995 and the uploading of SBC-2 r09 in May 2003, the word was "suspend" not "disable". It was 02-464r3 whose incorporation switched the word "disable".

Looking in 02-464r3 for an explanation of why is a fool's errand. Here's the entire introduction to the 12 pages of changes.

There have been several modifications and clarification to power conditions (e.g., moving several items from SBC to SPC and deleting the SLEEP condition). The following is an attempt to complete reconciliation of all of these, perform some clean-up, and remove duplication. This proposal is based on SAM-3r05, SPC-3r12, and SBC-2r08. Revision 2 of this proposal separated the subclauses for SPC and SBC that were recommended in revision 1 so that there is a model subclause for each of those draft standards. Revision 3 of this proposal includes some very minor editorial modifications that were recommended at the May 7th CAP working group meeting.

Thus, SBC-x morphed from the non-specific "suspend" to the all-too-specific "disable". The standard changed from giving implementations all-important latitude to do it their way to the grievously unhelpful wording that has modern developers reading the standard as containing a requirement to change the contents of the Power Conditions mode page.

In a delightful twist of fate,  Kevin Marks' suggestion to change of "disable" to "stop" is looking remarkably prescient, although "suspend" would have been more historically correct.

Flash forward to today

Clearly, a detailed proposal is required to drain this cesspool.

As resounding as changing the verb "to disable" to the historically correct "to suspend" would be, making only that change will not thwart future attempts to reinstate "disabled" as the word most frequently found by an Acrobat Search. The SPC-6 model needs some kind of "modal" ("state" being a dirty word in this case) definition for Power Condition timers.

This author's initial stab suggests the following "modes" for Power Condition timers

==> as nod to the bit definitions

  *   enabled, i.e., bit set to one
  *   ignored, i.e., bit set to zero

==> operational orientation

  *   active, i.e., capable of causing a state transition (includes enabled as a requirement)
  *   suspended, i.e., not capable of causing a state transition
  *   initialize (or reinitialize), i.e., set so that a state transition is possible in the mode-page specified time
  *   start (or restart), i.e., made active, if needed

The SPC-6 paragraph that CAP reviewed last Tuesday will need tweaks too, maybe along the lines of...

If a device server processes a command that the device server is not capable of completing while the logical unit is in a low power condition, then the device server shall ++suspend any active++ --stop any running-- power condition timers. On completion of the command ++and regardless of which power condition the logical unit was in when the device server began processing the command++, the device server shall reinitialize all enabled power condition timers based on their values in the Power Condition mode page (see 7.5.18) and start the timers, unless an applicable command standard specifies otherwise. --regardless of which power condition the logical unit was in when the device server began processing the command. --

Naturally, proper use of these definitions will need to be verified globally, with any necessary changes being made to either the definitions to any other text that (mis)uses them.

Remember: There is a WebEx scheduled on 18 August to discuss this, but... Don't delay posting discussion points for almost a month. Speak up on this reflector with whatever useful inputs come to mind.

All the best,
.Ralph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.t10.org/pipermail/t10/attachments/20210717/8ab33b09/attachment.html>