pass(4): always retry CAM_REQUEUE_REQ ccbs

[Andriy Gapon]

on 17/03/2010 19:28 Kenneth D. Merry said the following:
> On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote:
>> At present pass(4) never retries a request (or performs any other kind of error
>> recovery) unless the request has CAM_PASS_ERR_RECOVER flag set.
>> This gives applications a control over error checking and handling.
>> But I think that in the case of CAM_REQUEUE_REQ status error recovery,
>> specifically a request retry, should always be performed.
>>
>> Rationale:
>> CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem.
>> It doesn't convey any information about state of medium, device, bus, controller
>> or the ccb itself.  Application can not make any meaningful differentiation
>> based on this status.  It either should always retry a ccb with this status or
>> face truly random failures.  As such, I haven't encountered so far any
>> application that expects to get CAM_REQUEUE_REQ status.
>> So I think that CAM_REQUEUE_REQ should be contained within the CAM and never be
>> leaked to applications unless retry count is exhausted (to prevent endless loops
>> in case of programming errors, primarily).
>>
>> What do you think?
>> Do you see any reason not to do it?
> 
> Is there a particular case you're running into where CAM_REQUEUE_REQ is
> getting returned?

Yes, access to ATAPI devices with ahci(4).

> I think it's better to keep the model as-is, to avoid confusion.  Either
> the application is handling errors, and it can get any CAM status value, or
> it is asking the pass(4) driver to do error recovery and it doesn't have to
> handle things until error recovery is done and retries are exhausted.

I've had a chat with Justin Gibbs and he is of the same opinion.  His explanation
makes sense to me.  I didn't look beyond 'for home use' applications when I came
up with the suggestion.
So, I think that we'd better teach affected applications about CAM_REQUEUE_REQ.

> If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it
> shouldn't, we should probably look at that.  Retries can get used up for
> various target-related reasons, like unit attention conditions, and we
> don't want to use CAM_REQUEUE_REQ when it isn't really needed.

I guess that this would be ideal.
I think that it is an implementation detail in ahci(4) that some commands may get
CAM_REQUEUE_REQ status.  But I am not sure if there is an easy way to fix that
given the general logic in that driver.

-- 
Andriy Gapon