Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19

[Florian Schmidt]

On Thu, 2 Dec 2004 13:29:31 +0100
Ingo Molnar <mingo@xxxxxxx> wrote:

> it's very likely not the simple jack_test client. I've attached the
> trace in question. Here are the tasks that were running:
> 
>  gkrellm
>    IRQ 0
>   IRQ 14
>    IRQ 5
>    jackd
>  kblockd
>   korgac
> ksoftirq
> qjackctl
>   qsynth
>        X
>     xmms
> 
> the trace doesnt show what task jackd was waiting on, and it would be
> hard to establish it, the tracepoint would have to 'discover' all other
> holders of the pipe fd, which is quite complex.

I'm not knowledgable enough to read the trace, but what was for example
the last thing qsynth was doing? Did it go to sleep? I suppose this was
Rui's 9 qsynth's test, right?

Hmm, i wonder if there's a way to detect non RT behaviour in jackd
clients. I mean AFAIK the only thing allowed for the process callback of
on is the FIFO it waits on to be woken, right? Every other sleeping is
to be considered a bug. 

> 
> > Oh wow. Just before hitting send i got three xruns of around
> > 0.020-0.050msec. Ok, will read up on recent emails to see what to do
> > to debug these.
> 
> which jackd version is this? I saw similar small spurious xruns with
> 99.0, those went away in recent CVS versions.

For this test i used jackd from yesterdays CVS. With the 0.99 version i
think i saw more of these xruns, but cannot tell (still running the CVS
version right now).. They all had in common though that they are in the
0.020-0.040msec range.

Flo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/