[LAU] Regular Xruns?
quozl at us.netrek.org
Fri Aug 7 04:43:55 EDT 2009
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.
> # "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
> 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.
More information about the Linux-audio-user