Recent patch to aic7xxx.c

[Doug Ledford]

OK...the patch I sent to the list doesn't work (among other things, there
was a typo in the patch).  I thought I was runnign on the patch when I
sent it, but as it turns out, I wasn't because of my not recompiling the
kernel since I last re-installed the source code.  As a result, my INSTALL
variable in the top level Makefile was not properly set and the kernels I
was compiling were going into never never land.  In any case, I worked on
the patch before I finally had to get some sleep today, and now that I'm
back up, I'll be working on it some more tonight.  When I'm happy with it,
then I'll send it back to the list.  It appears as though a few things in
the linux header source code are incorrect (for instance, placing your
bottom half handler on the task queue tq_immediate does not cause your
bottom half handler to get run immediately when you exit your interrupt as
it should, so I had to switch over to tq_scheduler, which works because
the scheduler is run at the end of all interrupt contexts and the end of
all syscalls as well as on the timer interrupt, which is often enough to
provide reasonably quick running of the bottom half).  There is one
problem though, the bottom half handler is atomic with respect to itself,
and it is pre-empted by incoming interrupts, so the last testing has
indicated that as a result of very heavy interrupt load, the interrupt
routine can start to starve the bottom half handler and keep it from
finishing in time to avoid SCSI timeouts from the mid-level code.  I'll be
working later tonight on speeding up the running of the bottom half
handler in order to solve that problem and see if I can't stop the
abort/reset cycles it causes.  I'm not sure, but Dan mentioned he already
had a spin lock mechanism in place to solve the same problem that this
would solve (although it doesn't have the benefit of reducing interrupt
latency as well as over all time spent with interrupts off) so it may end
up being that it is easier to solve the problem that way (with less chance
of breakage as well) than to do things this way.  We'll see how the bottom
half handler goes tonight, but if I can't make it pump the commands out
fast enough to avoid timeouts, then it won't end up getting used anyway. 

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