Re: Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19
From: Andrew Burgess
Date: Thu Dec 02 2004 - 10:52:55 EST
Ingo Molnar said:
>Florian Schmidt <mista.tapas@xxxxxxx> wrote:
>>
>> 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.
>there's such a feature in -RT kernels. If a user process calls:
> gettimeofday(1,1);
>then the kernel turns 'atomic mode' on. To turn it off, call:
> gettimeofday(1,0);
>while in atomic-mode, any non-atomic activity (scheduling) will produce
>a kernel message and a SIGUSR2 sent to the offending process (once,
>atomic mode has to be re-enabled again for the next message). Preemption
>by a higher-prio task does not trigger a message/signal.
>If you run the client under gdb you should be able to catch the SIGUSR2
>signal and then you can see the offending code's backtrace via 'bt'.
Might be handy to have the option to send a SIGABRT, then you don't need
to guess which app to run under gdb and the offending code is there in
the core file.
Also, I'm cc-ing jack-devel. This could fit into libjack so no client
mods would be needed I think. After the thread_init_callback is run libjack
could run 'gettimeofday(1,1);' for each client thread. Then if any client
breaks the rules you get a core showing where.
On further thought, I suppose libjack could install a SIGUSR2 handler and
have that call abort for all the rt client threads. Still no client mods
needed, only an RT-aware libjack.
A big thank you to Ingo and everyone else involved on behalf of all the
linux audio users!
-
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/