Date: Tue, 09 Sep 1997 09:17:54 -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: <199709091417.JAA11378@dledford.dialnet.net> In-Reply-To: Your message of "Tue, 09 Sep 1997 07:33:00 MDT." <199709091336.HAA10939@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- > >Followed by a bunch more timeouts, then eventually a bus reset, then things > >went back to normal. I kind of liked seeing the qoutcnt = 17, that > >shouldn't ever happen since I'm running with the spin lock. > > Does your spin lock completely empty the FIFO before setting the sequencer > variable to 0? It doesn't sound like it. The 17 could simply be from > overflowing the QOUTFIFO as, although the documentation claims insertions > when full are a no-op, I'm not sure I believe it. Actually, the way I have the locking code in the kernel, there is a small chance of an overflow, although I haven't worked out exactly yet how it would occur. Instead of specifically setting the CMDOUTCNT to 0, I do the following: while ( qoutcnt > 0 ) { for(i=0; i<qoutcnt; i++) { do our stuff here } if (p->flags & PAGE_ENABLED) { pause_sequencer(p); // In case we ever have paging on 2{7,8}4x class cards outb(qoutcnt - i, p->base + CMDOUTCNT); //In most cases, this should be 0 unpause_sequencer(p, FALSE); // Do this before checking qoutcnt again } // so we might catch a blocked command outb(CLRCMDINT, p->base + CLRINT); interrupt_cleared++; qoutcnt = inb(p->base + QOUTCNT) & p->qcntmask; } This way, there is no possibility that as we unblock the sequencer in its spin lock that it could write to the QOUTFIFO (although it also couldn't if we didn't unpause it) and so that there is a good chance that if it is spin locking, we might be able to catch the interrupt and the command on this iteration of the while loop. However, although I don't see it anywhere, I guess there is a possibility that we could get into the for test with qoutcnt == 0, in which case the post increment to i would cause qoutcnt - i == 255 and allow the sequencer to overrun the QOUTFIFO the next time it had a lot of commands, but it would have to do so before the next interrupt reset the CMDOUTCNT variable. -- ***************************************************************************** * 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?199709091417.JAA11378>