Hello.  What I see is that after a few seconds of operation, the sound
card, an auich(4) device, which shares the interrupt with the ath(4)
driver, begins stuttering continuously for a second or two, then stops,
with the sound generating process in au_wr, according to ps(1).  Then,
vmstat -i shows a very high interrupt rate on the shared interrupt, greater
than 300/second, I believe, but don't remember.
If I ifconfig down the ath device, sound begins working again, normally.
	At first I thought it was a bug in the auich(4) driver, but I have
another machine where the auich(4) driver shares an interrupt with the
emuxki(4) driver, and they get along quite nicely.
	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.
	Thanks for the response, and thanksfor giving me another idea of where
to look.  If you have any other thoughts, I'm all ears.
-thanks
-Brian

On Nov 19, 12:28pm, Joerg Sonnenberger wrote:
} Subject: Re: Problems with ath(4) and interrupt sharing
} On Fri, Nov 16, 2007 at 06:32:18PM -0800, Brian Buhrow wrote:
} > 	In looking at the ath driver source code, I find I have a couple of
} > questions in ath_intr() in src/sys/dev/ic/ath.c
} > Here's the snippet, with my questions below that.
} > 
} > 
} >     810      if ((ifp->if_flags & (IFF_RUNNING|IFF_UP)) != (IFF_RUNNING|IFF_UP))
} >  {
} >     811           DPRINTF(sc, ATH_DEBUG_ANY, "%s: if_flags 0x%x\n",
} >     812                __func__, ifp->if_flags);
} >     813           ath_hal_getisr(ah, &status);  /* clear ISR */
} >     814           ath_hal_intrset(ah, 0);       /* disable further intr's */
} >     815           return 1; /* XXX */
} >     816      }
} > 
} > My questions are:
} > 
} > 1.  Does the call to ath_hal_intrset() disable the device from generating
} > interupts, or does it disable the interrupts from being acted upon,
} > regardless of which device on that interrupt generated them?
} 
} It stops the device from generating further interrupts. You haven't
} quoted the check for pending interrupts directly above this and the
} logic is that (a) if there's no pending interrupt it won't reach above
} block and (b) if it reaches the above block and the interface is not
} running, it stops further interrupts.
} 
} Do you see interrupt storms, e.g. vmstat -i gives interrupt rates >
} 1k/s? Otherwise this shouldn't be the problem.
} 
} Joerg
>-- End of excerpt from Joerg Sonnenberger