> Although this can't possibly be the right fix, it can hint us as
> to where it really is. All this patch does is single thread all
> interrupt handling, which means there is a re-entrancy problem in
> some driver still which has yet to be resolved.
Well I can even tell you the driver. However, the problem will
persist for all other drivers unless they are rewritten -- and I'm
sure that nobody wants to do that. I am quite aware what the patch
does.
Incorrect, I'd say %95 or more of the drivers behave properly under
the new scheme. There is one, only one, case where a driver would
need to be modified in some way to work properly in the new scheme
where all cpu's can service interrupts in parallel.
This case, as noted here many times, is when a driver disables
interrupts on the adapter itself and expects nobody else to be in an
interrupt service routine for that card, they must do a
synchronize_irq() after they disable interrupts on the _adapter_. (I
stress this, because things work just fine if interrupts are disabled
using disable_irq() or by using a cli())
---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><