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>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybu3dvgzaoj.fsf>