Behavior of TEST UNIT READY command in idle and standby power conditions
p.lavarre at ieee.org
Tue Nov 27 10:12:53 PST 2012
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1211273_f.htm">HTML-formatted message</a>
@ If there is a convergence of opinion, ...
Me, I've voted to ship both choices, in different contexts.
I shipped Test Unit Ready passing with Good status in low power, when I
could spin up fast enough to answer any Read within five seconds.
I shipped Test Unit Ready crashing via Check Condition status and throwing
Kcq's like x20402 Initializing Command Required or the rudely fuzzier x
20400 Cause Not Reportable, when I couldn't spin up fast enough to keep my
mass-market binary-code-only rarely-updated hosts from crashing in response
to my Target's automagic choice to reduce power and wear.
Changing a Target to signal low power by failing Test Unit Ready would
profitlessly bring all the host code crawling out of the woodwork that
doesn't expect that signal and also doesn't need to know about low power.
Changing a Host to poll with Request Sense would profitlessly crash all the
targets that don't expect that poll and don't report low power.
I'd hope that by now we've included plain simple reliable plug-n-pray
signals in the core leading x24 (36) bytes of the main Page of Inquiry to
tell the Host which kind of polling to try or neither.
Polling doesn't reduce power consumption.
Polling with Test Unit Ready can cost more power when the device returns a
Check Condition and then the host adds a Request Sense - so we spend all
the cost of Request Sense anyhow plus the cost of Test Unit Ready.
Polling with Test Unit Ready has been more popular = is now more polite -
than polling with Request Sense, which has been more often tested only
immediately after a Check Condition as part of clearing the Contingent
Allegiance. In my circles we spoke of, and sneered at, Unsolicited Request
Sense as being a Request Sense after status other than Check Condition.
Polling with Test Unit Ready is simpler = more reliable = more polite:
normally just Cdb and Good Status, abnormally Cdb and Check Condition
Status, never any Data to negotiate.
On Tue, Nov 27, 2012 at 9:19 AM, Matthew Jacob <mj at feral.com> wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Matthew Jacob <mj at feral.com>
> On 11/27/12 07:27, Gerry Houlder wrote:
>> Some questions have come up about the behavior of TEST UNIT READY command
>> when the target is in an idle or standby power condition.
>> One opinion is that TUR should be treated as a command that can be
>> processed in idle and standby power conditions, so therefore should
>> complete with GOOD status.
>> Another opinion is that TUR should respond with CHECK CONDITION status
>> with sense bytes indicating the target is in a low power condition and the
>> target should not attempt to change to a higher power condition. (Read or
>> write commands would trigger the target to change to active power
>> condition, so TUR action would be different). The advantage of this
>> behavior is that it could be used to poll for low power conditions in lieu
>> of using REQUEST SENSE command.
>> Why would this be any different than a TUR response for a spun down disk
> which responds with a check condition that asc that says in essence "need
> You know the unit is there and present because it responds to the TUR
> (with any status). You know that it isn't ready (for media access in the
> case of disk) because of the specific CHECK CONDITION response.
> * 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