29 Mar
2006
29 Mar
'06
11:39 a.m.
On Wednesday, 29. March 2006 10:50, Florian Schmidt 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.
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?
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. - 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? 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