From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 17 18:00:19 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 644DD106566B for ; Wed, 17 Mar 2010 18:00:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AABE78FC13 for ; Wed, 17 Mar 2010 18:00:18 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA19651; Wed, 17 Mar 2010 20:00:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4BA118AD.6050102@icyb.net.ua> Date: Wed, 17 Mar 2010 20:00:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: "Kenneth D. Merry" References: <4B978175.3030805@icyb.net.ua> <20100317172847.GA15531@nargothrond.kdm.org> In-Reply-To: <20100317172847.GA15531@nargothrond.kdm.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 18:00:19 -0000 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