Date: Wed, 17 Mar 2010 20:00:13 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-scsi@freebsd.org Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs Message-ID: <4BA118AD.6050102@icyb.net.ua> In-Reply-To: <20100317172847.GA15531@nargothrond.kdm.org> References: <4B978175.3030805@icyb.net.ua> <20100317172847.GA15531@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BA118AD.6050102>