Re: [linux-audio-user] Can't get rid of xruns

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?!

> > - 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.

> > - Changed filesystems from reiserfs to ext3 (/) and xfs (/home)
> might be good. no idea. i never ad trouble with ext3. But besides ext2
> i never tried any other fs's ;) I heard bad things about xfs though. Do
> you record to /home?

The predominant opinion seems to be that both ext3 and xfs are ok, if I'm
not mistaken. But I haven't heard a definite answer to which filesystem
is best, yet.
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?

> 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?

Thanks,
    Dominic
Received on Wed Mar 29 20:15:06 2006