Date: 12 Oct 1999 18:38:36 +0000 From: Randell Jesup <rjesup@wgate.com> To: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> Cc: Gerard Roudier <groudier@club-internet.fr>, scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller Message-ID: <ybu3dvgzaoj.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: "Justin T. Gibbs"'s message of "Tue, 12 Oct 1999 14:07:03 -0600" References: <199910122007.OAA02497@caspian.plutotech.com>
index | next in thread | previous in thread | raw e-mail
"Justin T. Gibbs" <gibbs@caspian.plutotech.com> writes:
>>(though it's very not-nice to do so). I assume the problem becomes
>>something like: command comes in with disconnect-disabled. You need
>>to page (or otherwise access a disk) to fufill the request. The disk
>>you need to access is on the same bus. Ooops. I forget if this was
>With resource reservation you can avoid the problem, but you need an
>interface for passing the resources to the peripheral driver handling
>the active transfer. In FreeBSD-CAM, where priority information is
>presented at the time a peripheral driver requests resources, we can
>simply pull the resources from a small pool for 'highest priority'
>requests. As neither CAM1 or 3 has the concept of scheduling for
>controller resources, there really isn't a clean way to deal with this.
I don't see how anything can work around selection-with-no-
disconnection-allowed, if the data to respond to the command is on
the same bus. The only solution would be to lock ALL code and data
required to process it into RAM - tricky. Best solution is to not
initiate to a processor device with reselect disabled.
--
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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybu3dvgzaoj.fsf>