Date: Tue, 12 Oct 1999 14:07:03 -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: <199910122007.OAA02497@caspian.plutotech.com> In-Reply-To: Your message of "12 Oct 1999 14:23:43 -0000." <ybubta4zmhc.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Well, you could always punt and return an error in that case >(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 >explicitly considered in the CAM subcommittee discussions, or if it was >just felt that this was something that could not be dealt with. I wouldn't >be surprised if we thought about it and agreed that it was not solvable, >and that an error return was perfectly reasonable, and that in this >sort of situation reselect-enabled was VERY strongly advised. 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. -- 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?199910122007.OAA02497>