Subject: Re: Problems with ath(4) and interrupt sharing
To: Brian Buhrow <buhrow@lothlorien.nfbcal.org>
From: Andrew Doran <ad@netbsd.org>
List: port-i386
Date: 12/09/2007 03:20:55
Hi,

On Sat, Dec 08, 2007 at 04:14:16PM -0800, Brian Buhrow wrote:

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

Device drivers return 1/0 to flag whether or not they serviced an interrupt.
For some time we have ignored that and called all of the handlers.

> Questions:
> 
> 1.  If two devices of different interrupt priorities share an interrupt,
> what is the interrupt priority set to when that shared interrupt fires?
>
> 2.  Is there a mechanism to set things up so that the highest priority
> device gets to be first in the interrupt chain?  Does it matter?

It will be set to the priority each handler was registered at, as each
handler is called, and the handlers are called in order of priority.

Cheers,
Andrew