Hello.  In looking into this further, the problem appears to be a
little different than I first described.  I've tried a couple of small
patches to the ath(4) driver with mixed results, but the basic problem
remains.  Here's what happens.

1.  If only the ath device is used, all works fine.

2.  If only the auich audio driver is used, all works fine.

3.  If they're used together, that is, both are active at once, then, at
some point fairly shortly after they both become active, all interrupts on
pin 9, which is the interrupt they share, stop.  The application using the
auich audio device gets stuck in aud_wr, according to ps(1).  Ifconfigging
ath0 down and up doesn't clear this condition, but killing the auich using
application does and then interrupts start up again normally.

	This makes me wonder if my problem is in the auich(4) driver rather
than the ath(4) driver.  On the other hand, I have another box, running
NetBSD-3.0 where the auich(4) driver shares an interrupt with a device
using the emuxki(4) driver, and all works fine there when both devices are
active.  Unfortunately, I can't test NetBSD-3 on this laptop because the
version of the Atheros card I have isn't supported with the older hal
module.

	Based on these observations, I now think that what I'm seeing is that,
for some reason, an interrupt gets asserted on pin 9 but that no one is
processing it.  My speculation is that the ath(4) gets first crack at the
interrupt, erroneously returns 1, saying it handled the interrupt, and the
interrupt subsystem clears the condition thinking all is well.  In the mean
time, the auich device, which raised the original interrupt, is left
hanging in the wind.  And, of course, no other interrupts can come in while
the interrupt remains raised, but the subsystem thinks it's already
handled.

	To test this theory, I wrote a patch to the ath(4) driver which
returns 0 if the interrupt came in for a reason other than the reasons the
ath(4) driver knows about.  This patch makes things behave better, but I
can still force the problem within a few minutes.  Now, what I think is
happening, is that an interrupt comes in, and both devices need servicing.
The ath driver returns 1 because it did need servicing, but the auich
driver never got a bite at the apple as a result.
Question, what's supposed to happen if an interrupt gets asserted and more
than one device on that interrupt needs servicing during that interrupt
cycle?

-thanks
-Brian
On Nov 19,  7:48pm, Joerg Sonnenberger wrote:
} Subject: Re: Problems with ath(4) and interrupt sharing
} On Mon, Nov 19, 2007 at 09:47:03AM -0800, Brian Buhrow wrote:
} > 	What I think is that the ath driver is fieldiing all interrupts, even
} > those for the sound card, and the block of code you mention is not working
} > quite right.  I'm  just starting to look at this, so my understanding of
} > 'what exactly is going on is a bit sketchy.  However, I am sure it's an
} > interupt issue, and I'm sure I need it to work right in order to make this
} > laptop usable for me.
} 
} The question is whether ath_hal_intrset does work or not. If it doesn't
} work correctly, you are right and ath will keep the interrupt "masked".
} The idea here is that a PCI interrupt remains raised if at least one
} device requests it. That's why it is safe to return 1 when the interrupt
} is handled -- it will get reraised by the hardware.
} 
} Just to make sure, print the current interface flags -- is IFF_RUNNING
} *not* set for you?
} 
} Joerg
>-- End of excerpt from Joerg Sonnenberger