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.
	As a test, I changed the ath(4) driver to never acknowledge any
interrupts as if it were never the initiater on a given interrupt sycle.  While
this made things marginally better, but the problem still occurs.  I also tried
putting a hard time out in audio_write() in an effort to see if I could get
things going again by brute force when they broke.  Again no dice.
Although the application using the audio device would drop out of
audio_write, interrupts would still not return to normal until the
application exited completely.
-Brian

On Dec 9,  5:11pm, David Laight wrote:
} Subject: Re: Problems with ath(4) and interrupt sharing
} 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
>-- End of excerpt from David Laight