MRIE behavior in SPC-2 vs SSC

Elliott, Robert (Hou) Robert.Elliott at
Tue Jun 8 09:59:31 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert (Hou)" <Robert.Elliott at>
> * From the T10 Reflector (t10 at, posted by:
> * gop at
> *
> Rob,
> I do not believe requiring the recovered error to occur on 
> the 'next SCSI
> command' is a behavior we want. It should state 'any command' 
> as is the case in
> the current SPC-2. The reason for this is that we will only 
> report a 'recovered
> error' on commands that the initiator would normally expect 
> to see a 'recovered
> error' (e.g., reads and writes) and that type of command may 
> not be the 'next'
> command.
> The same problem is in the definition on MRIE=3 in SSC.
> In general I am uneasy about the way these descriptions have 
> changed (i.e.,
> putting text in ( )) but not enough to make comments on.

One of our testing groups likes the SSC "next command" requirement because
it lets them test the host response to an error on each different command.
They set the test bit and timer to appropriate values before issuing each
command.  This helps exercise all the host software error-handling paths.
The SPC-2 "any command" rule makes it hard to force each command to error -
the device may hold off reporting until it receives a certain command (or
delay for any other reason).

If "any" were reduced to "next media access command" it would help (provided
those commands could be defined).  This would restrict the errors to appear
on a specific set of commands, all of which could be tested.  Historically,
devices tend to differ on whether they consider TEST UNIT READY a media
access, so this set might not be easy to define.

Something like "over temperature" can be detected without a media access.
It makes sense to report that ASAP rather than wait for a media access.  The
"next command" concept seems preferable for this situation.

An error caused by the TEST bit doesn't require a media access.  If only
these test errors were required to occur during the "next command," the
testing needs might be satisfied.  Each command could be tested.  If the
device in real operation only generated errors on certain commands, that
would just mean the host software is more robust (and ready for future
devices that report on different commands).

PC: Robert.Elliott at
UNIX: relliott at

* 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