Date: Tue, 12 Oct 1999 17:45: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: <199910122345.RAA03158@caspian.plutotech.com> In-Reply-To: Your message of "12 Oct 1999 18:38:36 -0000." <ybu3dvgzaoj.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
index | next in thread | previous in thread | raw e-mail
> 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. 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. 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. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910122345.RAA03158>