On Sat, Dec 08, 2007 at 04:14:16PM -0800, Brian Buhrow wrote:
> 	Hello.  In thinking about this even more, and doing a little source
> reading, I think my problem can be more succinctly stated.
> 
> 	The trouble seems to be that the ath(4) driver is in the interrupt
> chain ahead of the auich(4) driver.  Yet, the auich(4) driver establishes
> its interrupt at IPL_AUDIO, while the ath(4) driver establishes its
> interrupt at IPL_NET.  If my understanding of interrupt priorities is
> right, IPL_AUDIO is a higher interrupt priority than IPL_NET, meaning that
> if the machine is at interrupt IPL_AUDIO, all network interrupts will be
> blocked.  So, if the auich(4) driver asserts an interrupt, but never
> receives it, because the ath(4) driver ate it, the ath(4) driver will never
> receive another interrupt because it's being blocked by the currently
> running interrupt priority.

I wonder if the actual problem is that the auich driver doesn't correctly
handle its ISR being entered when the device isn't raising an IRQ.

A 'missing' interrupt would be picked up by the next ath interrupt and
everything should continue - if after a slight hiccup.

	David

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