pass(4): always retry CAM_REQUEUE_REQ ccbs

[Kenneth D. Merry]

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?

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.

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.

Ken
-- 
Kenneth Merry
ken at kdm.org