On Wed, 29 Mar 2006 16:35:11 +0200 Dominic Sacré <dominic.sacre@xxxxxx> wrote: > On Wednesday, 29. March 2006 10:50, Florian Schmidt wrote: > > 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?! Probably yes. Writing a non trivial app in a realtime safe way is sadly not trivial at all :) > > > - Installed a realtime kernel (currently 2.6.16.1-rt11) > > good, although it might be wise to try different versions. > > 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? > 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: 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. > > [ 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
