99-208r1 - MRIE behavior with TEST bit asserted

Elliott, Robert (Hou) Robert.Elliott at COMPAQ.com
Wed Oct 20 14:27:56 PDT 1999

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Hou)" <Robert.Elliott at compaq.com>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry_Houlder at notes.seagate.com
> *
> I have read Rob's proposed wording a couple of times:
> >The text I propose adding in several places is:
> >
> >    If TEST = 0, the status may be returned on any command
> >    after the informational exception condition occurs. If
> >    TEST = 1, the status shall be returned on the next
> >    command that is capable of returning an informational
> >    exception condition when TEST = 0.
> The TEST=1 case has a "shall" in it but then has the weasel 
> words "next comand
> that is capable of returning an informational exception 
> condition ..". The net
> effect of the weasel words is to negate the shall so the 
> initiator still can't
> be sure whether the next command should return a CHECK or 
> not, unless there is
> an agreed list of commands that "shall" always return the 

The intent is to create two bucketes of commands:
a) those that will never return an IE to software
b) that that could possibly return an IE to software

It is up to the target to define these buckets.  A target may only return
IEs on media access commands, for example.

In test mode, we want to trigger a fake IE and run each command.  If the
command is in bucket a), we don't want an IE returned.  That would cause us
to test a software path that is never used in real life.  If the command is
in bucket b), we want an IE returned immediately.  This ensures we test
every potential software path.  

> Is this really an improvement over the old wording?

Currently, "any" is too vague to be testable.  A target could choose to
defer reporting the IE for any amount of time it chooses.

> I would think one of the wider holes in this scheme is when 
> tagged queuing is in
> use. When the MODE SELECT command (that sets the TEST bit) 
> completes with GOOD
> status, how many of the queued commands will finish with GOOD 
> status (meaning
> they were at least partially processed before the Mode page 
> change took effect
> and could still be assuming the previous mode setting) before 
> the target gets to
> one that will report CHECK status? An initiator can control 
> this case, of
> course, by not doing the Mode Select command when there are 
> outstanding tagged
> commands. I'm not sure what case Rob is trying to describe, 
> but this wording
> doesn't add any more certainty than the old wording.

For testing we could certainly avoid queuing the commands to make the
results predictable.  Maybe that is appropriate material for a note?
PC: Robert.Elliott at compaq.com
UNIX: relliott at hobbit.eng.hou.compaq.com

* 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 mailing list