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

[David Young <dyoung%pobox.com@localhost>]

On Sun, Feb 01, 2009 at 12:33:35PM +0100, Manuel Bouyer wrote:
> On Sat, Jan 31, 2009 at 06:40:24PM -0600, David Young wrote:
> > > Log Message:
> > > Under some circunstance, the JMC250A2 (and maybe others) can enter a state
> > > where INTA is asserted while no enabled interrupts are pending, which
> > > cause a continous strean if interrupts with no way to clear it.
> > > Clearing/resetting the enabled interrupt mask in the interrupt handler 
> > > seems
> > > to workaround this issue (this is what the FreeBSD driver does).
> > > While there properly return 0 if the interrupt was not for us, and 
> > > explicitely
> > > disable JME_TMCSR in addition to TIMER1 and TIMER2.
> > 
> > Does FreeBSD enable/disable by changing the interrupt mask on the
> > NIC because that is the right / only workaround for this bug, or
> > do they do that because the change has been carried by the cargo
> > cult from driver to driver to driver?
> 
> 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.

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

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933