aic7xxx / AHA2940 worries... anyone?

[Doug Ledford]

--------

> 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 at 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.    *
*****************************************************************************