Date: Tue, 09 Sep 1997 20:30:34 -0500 From: Doug Ledford <dledford@dialnet.net> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Doug Ledford <dledford@dialnet.net>, "Daniel M. Eischen" <deischen@iworks.InterWorks.org>, aic7xxx@freebsd.org Subject: Re: Interesting anomoly with a 2940UW Message-ID: <199709100130.UAA21954@dledford.dialnet.net> In-Reply-To: Your message of "Tue, 09 Sep 1997 19:12:12 MDT." <199709100115.TAA28871@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- > >To be quite honest, I think most of the races you have mentioned in > >relation to my usage of the CMDOUTCNT variable exist not only in my code, > >but in yours as well. > > Nope. Since I only drop the count to 0 once I'm sure that the sequencer > has put fifodepth commands into the QOUTFIFO (as I have removed that many > from the FIFO), I'm guaranteed that CMDOUTCNT is equal to fifodepth. This > means that the sequencer is either in the spin lock or executing before > reaching the lock. This ensures that when I set CMDOUTCNT to 0, the FIFO > is truely empty and that the sequencer will increment CMDOUTCNT before it > places another entry in the FIFO. Ahh, well see, that's why I didn't do it that way. In that case, we would be hitting the spin lock right and left and the sequencer would spend way too much time locked down. Finding an acceptable solution to the isr handling the completion stuff would help, but it's tricky under linux. > >Does that sound any more efficient (and race protected) to you? > > It would be unacceptable to me to run with interrupts disabled for any > length of time in a disk driver especially when it isn't necessary. And in the future it may be possible to remove those interrupt off calls, but in the meantime, there were race conditions that needed something to protect them. It's been that way since I started working on the driver anyway, and we are starting to iron out some areas where we can turn them back on, but we haven't gotten around to removing all possible race conditions so that they can be unilaterally on without having the potential for problems. However, that is one of the things on my TODO list since it appears that the interrupt off situation can also cause problems with IRQ forwarding on SMP machines. But still, that doesn't answer the question. Does that solution sound race protected and more efficient than the current one I use? -- ***************************************************************************** * Doug Ledford * Unix, Novell, Dos, Windows 3.x, * * dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician * * PPP access $14.95/month ***************************************** * Springfield, MO and surrounding * Usenet news, e-mail and shell account.* * communities. Sign-up online at * Web page creation and hosting, other * * 873-9000 V.34 * services available, call for info. * *****************************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709100130.UAA21954>