Date: Tue, 12 Aug 1997 01:09:50 -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>, welbon@bga.com, aic7xxx@FreeBSD.ORG Subject: Re: aic7xxx / AHA2940 worries... anyone? Message-ID: <199708120609.BAA24140@dledford.dialnet.net> In-Reply-To: Your message of "Mon, 11 Aug 1997 21:57:12 MDT." <199708120357.VAA03849@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- > At one point I did add a combination of code into the sequencer and kernel > to "spin-lock" if the queue became full. In reality, it shouldn't be > necessary unless there is extremely high interrupt latency. Well, that is part of the problem here. After all, at the end of aic7xxx_isr() we turn around and call the (funct *)cmd->done(cmd) for each scsi command that has completed, and at that time a new command gets sent to our queue, which we then promply do an allocate_scb(), followed by buildscb() for that command, and then stick it on a queue of our own, then when all commands have been processed in this fasion, we call run_waiting_queues() to send these queues out. During all of this work, the code that yanks the scb numbers from QOUTFIFO is effectively shut off since this is all done in our declared interrupt handler which the kernel forces non-reentrance on even if we get mroe interrupts while we are doing all of this processing. > I should probably re-introduce this into the FreeBSD driver in the short term > since the driver currently in the source tree does have "high completion > queue processing latency". We get into the interrupt handler soon enough > to keep the queue drained, but each command that is removed from the queue > is handed up to the higher SCSI layers for what can be a large amount of > work. This makes queue draining a sometimes slow process. See above :) Really, the option to fix this in our driver (under 2.0.31-pre-4) is actually a farily easy fix. It can be done in one of two ways. Either we could define an exit function for our isr function (meaning in reality a bottom half handler that would run outside of the interrupt context and therefore not block the interrupt context from running), or we could set a timer function that runs at the next jiffie after any given interrupt (the less preferable but most likely easier way to get this accomplished). In either case, I'll look into it and see if I can't have a patch by sometime tomorrow to help out with this. I would think that Ed would be a good test candidate to try said patch out :) > As for what happens when you attempt to stuff an entry into a full queue > on the aic7880, aic7870, and aic7770, the data book says that it is a > no-op. The aic7850 data book says that the QOUTCNT will increment. As > always, any claims that the data books make should be verified by > experiment. But of course ;) I just didn't know if you had tried it out yet. For instance, when we get a warning that we have a CMDCMPLT interrupt near QFULLCNT and QOUTCNT=16 (on the 2940), does that mean then that we actually could have lost a command and the counter stayed at 16? From what the databook says, yes, that is a possibility. -- ***************************************************************************** * 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?199708120609.BAA24140>