On Sun, Dec 09, 2007 at 09:19:27AM -0800, Brian Buhrow wrote:
> 	Hello David.  Well, you might be on to something there.  At least
> asfar as the auich driver not properly handling interrupts it didn't
> generate.  However, Once the auich device misses an interrupt, interrupts
> stop coming in on that irq at all, and the ath driver begins to complain of
> device timeouts, leading me to believe that all  interrupts for that irq
> are blocked when this condition occurs.

Ah - I didn't remember you saying that both drivers lost interrupts.

Since the PCI interrupts are level sensitive that is quite hard for a
device driver to manage!

Another possibility is that when you disable an interrupt, all that actually
happens is that the kernel remembers that the interrupt shouldn't happen.
When one does happen (while disabled) it is then masked out on the
interrupt controller.

Possibly this is all going wrong when the interrupt should be unmasked
and it is being left masked.
Maybe either:
1) when an interrupt happens during the 'enable' sequence
2) the code is looking at the wrong priority level when two devices
   with different priorities share the same IRQ (which (I think) forces
   them both to use the lower priority.

	David

-- 
David Laight: david@l8s.co.uk