29 Mar
2006
29 Mar
'06
12:28 p.m.
On Wed, 29 Mar 2006 16:35:11 +0200
Dominic Sacré <dominic.sacre(a)gmx.de> wrote:
I did. I used various versions of 2.6.12, 2.6.15 and 2.6.16 with the
respective realtime patches, same result.
And i suppose you also had the priorities setup similar to your current
setup right?
The preemption check actually checks only for one class of realtime
violations: Those where the app gives up the cpu volountarily (due to
using non rt safe calls that consequently make the process go to sleep).
There's yet another class of realtime unsafeness: Simply taking too long
in the process callback. If the period is i.e. 10 ms, and the app needs
20 ms you get an xrun although the app never gave up the cpu
volountarily.
On Wednesday, 29. March 2006 10:50, Florian Schmidt
wrote:
Probably yes. Writing a non trivial app in a realtime safe way is
sadly not trivial at all :)
Some jack apps are badly programmed and start
up/shut down in a non
realtime safe way. I.e. jack-rack _always_ produces an xrun on
shutdown.
Well, this seems to be application dependent. I have not seen any xruns
caused by ardour, for instance. On the other hand, rezound causes xruns
all the time (usually a few at startup, and then occasionally some
when "doing something"). I've also seen xruns when starting/shutting down
jamin, rosegarden, muse, jack-rack, xfst... Are all these apps broken?! - Installed a realtime kernel (currently
2.6.16.1-rt11)
good, although it might be wise to try different versions. I'm recording to /home on xfs, but as most xruns
occur during
startup/shutdown, this doesn't seem to be the issue, does it?
As ardour runs xrun free while recording to the very same disc is
suppose we can rule that out.
This also gives a pretty strong hint about the brokenness of the other
apps. If ardour, a very complex nontrivial app, gets it right and
produces no xruns, but other apps do, this is a strong indicator for the
brokenness of the other apps.
If you are
really willing to hunt these xruns down you can compile
jackd with --enable-preemption-check. You also need to have user
triggered tracing enabled in the -rt kernel for this.
Now everytime an app does rt unsafe stuff in its callback that causes
the app to lose the cpu to another app, the kernel will send it a
SIGUSR2 and the app will probably terminate due to it ot handling this
signal.
You will also get a stack trace in the syslog which tells you what
happened in the app and which app it was.
Ok, I did that. Doesn't seem to have an effect on most apps though.
Rosegarden, rezound and jack_rack all caused xruns, but none of them was
terminated, and there's no stack trace either.
However I got a stack trace when shutting down jamin:
[ 4797.602341] jamin:17931 userspace BUG: scheduling in user-atomic
context!
[ 4797.602362] [<c01049f5>] show_trace+0x25/0x30 (20)
[ 4797.602382] [<c0104a23>] dump_stack+0x23/0x30 (20)
[ 4797.602395] [<c02bfa64>] schedule+0x114/0x140 (36)
[ 4797.602412] [<c02bfda4>] wait_for_completion+0xa4/0xe0 (48)
[ 4797.602426] [<c017bb68>] do_coredump+0x348/0x780 (192)
[ 4797.602456] [<c012edf1>] get_signal_to_deliver+0x391/0x510 (60)
[ 4797.602473] [<c0102c68>] do_notify_resume+0xb8/0x75c (220)
[ 4797.602486] [<c01034fc>] work_notifysig+0x13/0x1b (-8116)
[ 4797.602498] ---------------------------
[ 4797.602504] | preempt count: 00000000 ]
[ 4797.602511] | 0-level deep critical section nesting:
[ 4797.602518] ----------------------------------------
What does that mean?
This gives you a clue about what system call/code path in the kernel
caused the volountary giving up of cpu.
To find out what the app did to produce this behaviour, build the app
with debug symbols, and eiter run it in gdb or do ulimit -c unlimited
and examine the core after the app got terminated (it will dump a core)
with gdb.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org