Date: 13 Oct 1999 16:06:16 +0000 From: Randell Jesup <rjesup@wgate.com> To: "Justin T. Gibbs" <gibbs@caspian.plutotech.com>, Gerard Roudier <groudier@club-internet.fr>, scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller Message-ID: <ybuu2nvxn2f.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: "Justin T. Gibbs"'s message of "Wed, 13 Oct 1999 12:11:38 -0600" References: <199910131811.MAA04294@caspian.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin T. Gibbs" <gibbs@caspian.plutotech.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybuu2nvxn2f.fsf>