aic7xxx / AHA2940 worries... anyone?

[Daniel M. Eischen]

> 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.  The algorithm 
> I used in the past was to keep a count in scratch ram and in the driver
> of the number of commands that have been entered/removed from the queue.
> When that count reaches the full count value, the kernel driver pauses
> the sequencer and clears the counter to 0.  This approach limits the number
> of accesses (and hence pause operations) that need to be performed and,
> given sufficiently low interrupt latency, should make hitting the spin lock
> a low probability since you have one full command completion time to
> enter your interrupt routine and clear the counter.
>
> 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.

It is the same in Linux.  Every completed command is handed off to the
higher-level SCSI layer to be processed.  But we do not do this until
after we remove all the SCBs from the QOUTFIFO, so you wouldn't
expect this problem on a single controller.  But, if you had 3
different controllers, all very active, this might be a problem.
I think we should reintroduce this into the Linux driver also.

Dan Eischen
deischen at iworks.InterWorks.org