Question on RECOVERED ERROR handling

[Gerry Houlder]

The wording you just included in your message describes situation (c):

(c) Command A (the one for which the Deferred Recovered Error information was 
reported) completed successfully because the error recovery action was 
successful. This command had previously reported GOOD status for itself. In 
this case no error recovery action is needed for that command.
     Command B (the command that ended with CHECK status, deferred error sense) 
is not executed. A recovery action for this command is needed.

Thus the statements you included in your message aren't contradictory, those 
statements refer to the results of different commands. The wording of the 
standard doesn't necessarily reflect actual implementations, however, so your 
question is valid.

Note that the wording of the standard requires "command B" to be aborted even 
though it could be successfully executed. This can cause a lot of bother for a 
driver when deferred errors occur. Thus a target designer should minimize the 
reporting of deferred errors.

        STEPPING ONTO SOAPBOX ...
 In my opinion, recovered errors (things that will never require a recovery 
action) shouldn't be reported as deferred errors. This will cause recovered 
errors to be swept under the rug and not reported, but if the host really cared 
about recovered error reports it shouldn't be doing "immediate" commands. 
Deferred errors should only be used to report unrecovered errors (things that 
will always require a recovery action).

     Vacating soapbox...