From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 27 02:46:55 2006 Return-Path: X-Original-To: scsi@freebsd.org Delivered-To: freebsd-scsi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9CF916A407; Wed, 27 Sep 2006 02:46:55 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA7E543D49; Wed, 27 Sep 2006 02:46:54 +0000 (GMT) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id k8R2krik005494; Tue, 26 Sep 2006 19:46:53 -0700 (PDT) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id k8R2krVU005491; Tue, 26 Sep 2006 19:46:53 -0700 (PDT) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Tue, 26 Sep 2006 19:46:53 -0700 (PDT) From: mjacob@freebsd.org X-X-Sender: mjacob@ns1.feral.com To: Ade Lovett In-Reply-To: <92A8EEB3-28FD-45A2-8099-AD0942820C4B@FreeBSD.org> Message-ID: <20060926193731.G5448@ns1.feral.com> References: <20060926085839.Q98053@ns1.feral.com> <4519A603.8080108@samsco.org> <92A8EEB3-28FD-45A2-8099-AD0942820C4B@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scsi@freebsd.org Subject: Re: hysteresis for CAM_RESRC_UNAVAIL X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 02:46:55 -0000 > On Sep 26, 2006, at 15:13 , Scott Long wrote: >> I think the intent here was to have some sort of an asynchronous "resource >> is now available" and "I'm no longer busy" mechanism, maybe via an AC_ >> message. However, a think that the timeout that you're proposing is much >> better than the vacuum that is there now. > > Definitely the goal should be towards an async notification mechanism. The trouble here is that there is nothing in the SCSI spec to tell you *when* a device that reported a BUSY will no longer be busy. In the case of the return for CAM_RESRC_UNAVAIL that came out of the mpt driver it turns out that this is info out of the IOC with no info as to when resources *will* become available again either. In both of these cases, an async notification mechanism would be timeout driven at the sim level. > In the meantime, rather than hard-coding half a second, could we have the > timeout be a sysctl for easier experimentation as to what an "appropriate" > value would be? (defaulting to 500ms) Gives a few extra options to tinker > with things if a suitably degenerate case can be found with which to exercise > this code, rather than having to recompile the kernel. Providing > progressively longer delays on repeated calls to cam_periph_error() seems to > be somewhat non-trivial since it's going to require maintaining extra state. Umm- but then this has to be documented, and so on and so forth. I mean, you might have to tune such a value, but it strikes me that under the current circumstances that because nobody has *really* complained about this situation for > 5 years that nobody will really *need* to tune it, so maybe we need not do it at all :-). Maybe this should be pushed off to each SIM driver then. That is, let each SIM (or otherwise setter of BUSY or CAM_RESRC_UNAVAIL status) just freeze the device queue or simq as appropriate and then unfreeze it later. -matt