Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.9-mm1-V0.4]

[Ingo Molnar <mingo@elte.hu>]

* Lee Revell <rlrevell@joe-job.com> wrote:

> Here is the dmesg output.  It looks like the problem could be related
> to jackd's printing from the realtime thread.  But, this has to be the
> kernel's fault on some level, because with an earlier version I get no
> xruns.

with the earlier version these spinlocks were simply disabling
preemption, while now they will schedule away on contention. If that tty
lock is held for a long time by a lowprio task then that could delay the
highprio thread. We are starting to see priority inversion problems. 
But, the core issue is doing tty printouts - does jackd do that
periodically, or only as a reaction to an already existing latency?

> jackd:1846 userspace BUG: scheduling in user-atomic context!
>  [<c01069fc>] dump_stack+0x1c/0x20 (20)
>  [<c0283e60>] schedule+0x70/0x100 (24)
>  [<c0119efa>] do_exit+0x29a/0x500 (24)
>  [<c011a196>] sys_exit+0x16/0x20 (12)
>  [<c0106367>] syscall_call+0x7/0xb (-8124)

this one is interesting - does the jackd highprio thread start new
threads and lets them exit? The above schedule() is the final one of an
exit()-ing thread.

> jackd:1854 userspace BUG: scheduling in user-atomic context!
>  [<c01069fc>] dump_stack+0x1c/0x20 (20)
>  [<c0283e60>] schedule+0x70/0x100 (24)
>  [<c0119efa>] do_exit+0x29a/0x500 (24)

same exit() scenario. That would be pretty much a no-no, a new child
thread inherits the parent's SCHED_FIFO priority and due to
child-runs-first it could delay the parent possibly indefinitely.

	Ingo