Date: Wed, 13 Oct 1999 12:11:38 -0600 From: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> To: Randell Jesup <rjesup@wgate.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Gerard Roudier <groudier@club-internet.fr>, scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller Message-ID: <199910131811.MAA04294@caspian.plutotech.com> In-Reply-To: Your message of "13 Oct 1999 11:22:35 -0000." <ybuzoxny078.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>"Justin T. Gibbs" <gibbs@caspian.plutotech.com> writes: >>In this scenario you can return BUSY status. The scenario I want to >>avoid is that you have run out of controller resources to actually >>tell the controller to return BUSY status. There are controllers >>(like the aic7xxx chips) where having pending accept ccbs does >>not consume any controller resources, but outstanding continue target >>I/O or scsi I/O operations do. > > Really? Sure. If your target role is idle, why would you want to have it prevent your initiator role from running at full capacity? >> 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. >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. 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. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910131811.MAA04294>