site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Godfrey On Dec 3, , at 9:11, Mark Cookson wrote: 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. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... You could try latency -it, it will tell you if some other process is blocking interrupts for too long. 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. Any ideas about how I could track this down further? This email sent to site_archiver@lists.apple.com