Re: Interrupt delays
Re: Interrupt delays
- Subject: Re: Interrupt delays
- From: Godfrey van der Linden <email@hidden>
- Date: Fri, 3 Dec 2004 11:14:54 -0800
You could try latency -it, it will tell you if some other process is
blocking interrupts for too long.
Godfrey
On Dec 3, , at 9:11, Mark Cookson wrote:
I'm trying to track down an issue where it appears that our PCI card's
primary interrupt is delayed (in some cases more than 9 milliseconds)
from
when I would have expected to have seen it.
Since we make audio hardware, our driver needs to give accurate timing
information to CoreAudio. We do that by calling clock_get_uptime()
from our
primary interrupt. More specifically, we check that it was our card
generating the interrupt, if it was, call clock_get_uptime, then clear
the
interrupt, and return "true" so that our secondary interrupt handler
gets
called. The secondary interrupt is when we actually post the time
collected
by the primary interrupt routine.
We are logging the delta between these time stamps (via HALLab) and
see them
coming very regularly, as expected, except that on occasion on the new
1.8
GHz G5 with PCI slots (as opposed to the original 1.8 GHz G5 that had
PCI-X
slots) we see the delta grow by a very large amount, up to 9ms in one
case.
I believe it is this rogue time stamp that is causing our problems, but
since the time stamps are directly related to the primary interrupt, it
seems that something is preventing our primary interrupt from running.
Any ideas about how I could track this down further?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden