Enabling interrupt filters by default

[Marius Strobl]

On Wed, Apr 15, 2009 at 05:37:09PM -0400, John Baldwin wrote:
> On Wednesday 15 April 2009 4:36:30 pm Marcel Moolenaar wrote:
> > 
> > On Apr 15, 2009, at 1:13 PM, John Baldwin wrote:
> > 
> > > On Wednesday 15 April 2009 2:04:14 pm Marcel Moolenaar wrote:
> > >>
> > >> On Apr 15, 2009, at 10:24 AM, John Baldwin wrote:
> > >>
> > >>> A while ago I changed the interrupt code in 8.x such that all the MD
> > >>> code was
> > >>> the same for both the INTR_FILTER and non-INTR_FILTER case.  I would
> > >>> like to
> > >>> flip the switch to enable INTR_FILTER by default.  Any objections?
> > >>
> > >> Last time it was found to be not working. Did we fix it?
> > >
> > > Err, when was that?
> > 
> > August 2007.
> 
> I rototilled all the MD interrupt code to make both the filter and !filter MD 
> code identical and both sets use the same callout routines (post_filter, 
> etc.) in April 2008.
>  
> > >  I know folks have used it on amd64 and i386 ok and I have
> > > tested it on both of those platforms.  One of the arm kernel configs  
> > > uses it
> > > by default.
> > 
> > There was interrupt starvation on sparc64. There were also
> > issues with permanently masking stray interrupts. This is
> > problematic when interrupts are shared and there is at least
> > 1 filter on it.
> > 
> > FYI,
> 
> The MD interrupt code has changed quite a bit since then and I explicitly 
> worked with marius@ and others to test the aforementioned changes (though 
> various platforms may have only tested the !filter case at the time).

The MI part of INTR_FILTER still doesn't work properly when
multiple filters share one interrupt, resulting in a hang
during device attachment. After reviewing the INTR_FILTER code
back in August 2007 scottl@ wrote a private mail to marcel@
and me confirming that problem and saying he even found more
and even excusing for having pushed the switch to INTR_FILTER
for 7.0. Given that the INTR_FILTER code in kern_intr.c for the
most part seems unchanged since piso@ committed it probably
means that these problems still exist today. Apart from the
problem when filters share an interrupt, INTR_FILTER looked
good on sparc64 though last time I tested.

Marius