On Fri, Aug 07, 2009 at 09:09:56AM +0100, James Stone wrote: > uname -a > Linux 2.6.29 #1 SMP PREEMPT RT Fri Aug 7 02:24:17 BST 2009 i686 GNU/Linux > cat /proc/interrupts > ERR: 6 That ERR is interesting. Does the xrun correspond to increments of ERR? > ~/jack_stuff$ ./irq_check 5 > pid 2106's current scheduling policy: SCHED_FIFO > pid 2106's current scheduling priority: 99 One of the things that increased priority on an IRQ doesn't do is prevent other drivers from hogging the CPU during an interrupt. All drivers that handle interrupts can be a cause, if they contain coding flaws. If you can remove all drivers you don't need, reducing the /proc/interrupts list of drivers to a bare minimum, you can effectively exclude some of the problem space. > start) > # "open up" the PCI bus by allowing fairly long bursts for > all devices, increasing performance > setpci -v -s "*:*.*" latency_timer=b0 Does the problem happen without this line? I can imagine that a flawed PCI transaction might take a lot longer than it should, and if you increase the latency timer it may allow for more time not doing anything. > But still get xruns every 14 mins!!! Fascinating. This will make it easier to diagnose if it happens so regularly. Things I think you should try: 1. be in a text console (chvt 1) at the time of one of the expected events, and see if it still occurs ... this is so that you can exclude interrupts from your graphics adaptor as being a contributor, since I note that there are many interrupts counted on IRQ 10, which is shared between USB and Nvidia. 2. disconnect all unnecessary USB devices, see if the problem goes away, since I note that there are many USB interrupts counted on IRQ 10 and 11, ... you might even go so far as disconnecting a USB keyboard and mouse for the time of one of the expected events. 3. look for cron events around that time, e.g. by reading the cron configuration files, or brute force using "strace -o cron -p `pgrep cron`", to see if the overrun is contributed to by scheduled activity. -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
