Re: Interrupt delays
Re: Interrupt delays
- Subject: Re: Interrupt delays
- From: Mark Cookson <email@hidden>
- Date: Fri, 03 Dec 2004 16:07:07 -0600
So if latency doesn't show anything worse than 200us and yet our time stamp
has a delta off by 5+ ms, any ideas?
Our PC developers say that this looks like a PCI controller issue that
they've seen where the DMA requests from the card don't get honored. The
card doesn't reissue the request (no buffer, if it doesn't get the data,
it's too late to retry) causing the input and output DMA engines to get out
of sync with each other.
Since a fundamental assumption of our driver (and many CoreAudio
applications) is that the input and output are locked together, we only have
one time stamp, driven from the input interrupt. If the DMAs get out of
sync, our time stamp will be wrong, and we're up the proverbial estuary
without a means of locomotion.
I've filed a Radar issue on this, but not gotten any response to it.
Thanks,
Mark
--
Mark Cookson
M-Audio, a division of Avid
225 Locust St.
Hudson, WI 54016
On 12/3/04 1:14 PM, "Godfrey van der Linden" <email@hidden> wrote:
> 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