Re: CVS commit: src/sys/dev/pci

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Feb 01, 2009 at 12:56:25PM -0600, David Young wrote:
> > They do it because it's the right thing to do in their interrupt system
> > (the interrupt handler defers interrupt processing to a kernel thread).
> 
> I did not know that.  Sounds like NetBSD is the cargo cult, then.
> :-)
> 
> Seriously, though, NetBSD has adopted many network drivers from
> the other BSDs that fiddle with the interrupt mask at the top and
> bottom of the interrupt handler.  That is ordinarily a waste of
> cycles on NetBSD, and it can also cause subtle bugs.  ISTM that if
> the PCI write that re-enables interrupts is posted, then the next
> interrupt may be arbitrarily delayed.

I'm not sure bus_space allows write posting

> 
> > > Maybe you should disable/enable
> > > only if INTA seems to be stuck?
> > 
> > How do we know if INTA is stuck ? Especially when it's shared with other
> > devices ? I guess this will require more cycles than the 2 single
> > writes to the adapter's registers required to do this.
> 
> I don't think that you can know if INTA is stuck.  Maybe you can
> avoid the two register writes every time that the interrupt status
> register indicates events of interest really did occur.  I will
> grant that it may not make much difference in the speed of the ISR.

that's going to make the code more complicated, with branches and possibly
extra register reads. Especially in the case of shared interrupts, you'd
do 2 register writes every time an interrupt comes from another device. It's
really not clear this would be a win, and increases the opportunity of 
a bug to slip in.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--