From owner-freebsd-scsi Wed Oct 13 13:10:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id D946B14FCD for ; Wed, 13 Oct 1999 13:10:50 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id QAA21571; Wed, 13 Oct 1999 16:04:01 -0400 (EDT) Reply-To: Randell Jesup To: "Justin T. Gibbs" , Gerard Roudier , scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller References: <199910131811.MAA04294@caspian.plutotech.com> From: Randell Jesup Date: 13 Oct 1999 16:06:16 +0000 In-Reply-To: "Justin T. Gibbs"'s message of "Wed, 13 Oct 1999 12:11:38 -0600" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" writes: >>> If you expend all of your resources >>>on active, but disconnected, transactions and a selection without >>>disconnect occurs, you are deadlocked if you can't ensure the peripheral >>>driver that will handle the selection has controller resources to play >>>with. >> >> Which resources are those? > >The equivalent of CCB resources. You usually have a fixed number of >transactions you can queue to the card. Aha... >>This seems very strange to me - I >>can't imagine what resources would be required in order to return BUSY >>that might not be available. Even if that's true, it sounds like a problem >>with the driver design. > >If the accept occurs when all resources are consumed, sure, you know to return >busy. But that need not be the case. It could be that you receive the command >from the initiator, ship it off to your peripheral driver, and by the time it >can respond, other peripheral drivers have queued work that will take all of >your resources. Aha. That makes some more sense. > Since FreeBSD-CAM imposes a scheduling for resources, and >the XPT knows the total number of resources you have, the peripheral driver >you really want to have a resource doesn't happen to get it. The result is >deadlock. To avoid this, the peripheral driver needs to understand that >it should raise its response to the highest priority level so it is guaranteed >to get a resource. I'll need to look at the FreeBSD-CAM/XPT. None of the driver designs I've ever done have had any inherent limitations on the number of active requests (other than physical memory). I wonder if the XPT (or SIM) could reserve resources for target-mode driver responses... Part of the problem is not understanding FreeBSD's XPT's resource-allocation code. I think I really need to start looking at the code; perhaps this weekend. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message