aic7xxx / AHA2940 worries... anyone?

[Doug Ledford]

--------

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

> 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 :)

OK...I set down and made a small patch that does what I was talking about.  
Here's how I implemented the changes:

We keep a per host task queue struct as part of the aic7xxx_host struct.  
This task queue struct gets to define a function pointer and on data 
pointer.  In this case, the function is aic7xxx_isr_bh and the data pointer 
is struct aic7xxx_host *p itself.  In this fasion, we reduce the amount of 
processing during interrupts greatly and immediately after all interrupts 
have exited, our bottom half handler is ready to run.  We gaurantee 
non-rentrance into the bottom half handler in two ways.  First, bottom half 
handlers are suppossed to be gauranteed non-reentrance by the kernel anyway 
(although I'm sure this is dependant on how your structures are set up and 
if the kernel can keep track of different structs calling the same function, 
which I bet it can't).  So, since the different task structs all call the 
same function, we need to do our part for the re-entrance.  This is actually 
simple since the bh handler is re-entrant capable with respect to different 
host structures (no local variables at all, nor any static variables used 
other than the host struct).  So, in the isr, we simply check if we are 
currently in the bh handler for any particular instance of p, if so, we 
don't add a new bh handler call to the task queue, if we aren't, and we need 
to, then we do add one.  In any case, there might be one race in there that 
I haven't taken care of, but I've at least recompiled and rebooted this 
driver on my machine to make sure it works fundamentally, fine tuning can 
come after I get any bug reports (OK..so I just sat down and modified the 
patch again to make sure that race doesn't exist).  So, Ed, please try this 
patch out and see if it helps you when running large bonnie tests.  And here 
we go! :)   (Let me know if you can't get this becuase it's MIME encoded)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-patch
Size: 3255 bytes
Desc: aic7xxx-bh.patch
Url : http://lists.freebsd.org/pipermail/aic7xxx/attachments/19970812/5bb7f6be/attachment.bin