[chuck-dev] RT safeness check

[Florian Schmidt]

Hi,

i lately updated the chuck cvs repository and tried to run jackd with
Preemption checking enabled (this tells us about whenever chuck's
process() callback is preempted due to it using a blocking system call
(a no-no in jackd process callbacks, unless you want to provoke xruns
eventually)):

Test scenario:

jackd -R -C -d alsa -d hw:1 -p 128

The -C option enables preemption checking provided that

a] jackd was built with --enable-preemption-check

b] a realtime preemption kernel is running with latency tracing enabled


~/source/build_stuff/chuck_dev/v2/examples$ ../chuck -p9999 --loop

~/source/build_stuff/chuck_dev/v2/examples$ chuck -p9999 + otf_01.ck 


running otf_01.ck it seems some code is doing fs access (loading the
.wav file maybe?):


[  412.026048] chuck:1995 userspace BUG: scheduling in user-atomic context!
[  412.026074]  [<c01039ef>] dump_stack+0x1f/0x30 (20)
[  412.026098]  [<c03029c7>] schedule+0x107/0x130 (28)
[  412.026122]  [<c0303313>] io_schedule+0x13/0x20 (8)
[  412.026136]  [<c01497cc>] sync_page+0x3c/0x50 (12)
[  412.026159]  [<c030358a>] __wait_on_bit_lock+0x4a/0x70 (32)
[  412.026173]  [<c014a034>] __lock_page+0x54/0x60 (44)
[  412.026185]  [<c014a7cd>] do_generic_mapping_read+0x2fd/0x6e0 (132)
[  412.026199]  [<c014ad98>] __generic_file_aio_read+0xe8/0x250 (100)
[  412.026212]  [<c014af57>] generic_file_aio_read+0x57/0x90 (44)
[  412.026225]  [<c016ad7a>] do_sync_read+0xba/0x110 (160)
[  412.026239]  [<c016ae95>] vfs_read+0xc5/0x1b0 (40)
[  412.026251]  [<c016b28c>] sys_read+0x4c/0x80 (44)
[  412.026263]  [<c0103386>] syscall_call+0x7/0xb (-8116)
[  412.026276] ---------------------------
[  412.026283] | preempt count: 00000000 ]
[  412.026289] | 0-level deep critical section nesting:
[  412.026295] ----------------------------------------
[  412.026302] 
[  412.026307] ------------------------------
[  412.026313] | showing all locks held by: |  (chuck/1995 [ee6630c0,  90]):
[  412.026326] ------------------------------
[  412.026333] 

Here's a bt (dunno how useful that is):

(gdb) set arg -p9999 --loop
(gdb) run
Starting program: /home/tapas/source/build_stuff/chuck_dev/v2/chuck -p9999 --loo
p
[Thread debugging using libthread_db enabled]
[New Thread -1212279104 (LWP 2147)]
[New Thread -1212347472 (LWP 2151)]
[New Thread -1220736080 (LWP 2152)]
[chuck](VM): sporking incoming shred: 1 (otf_01.ck)...

Program received signal SIGUSR2, User defined signal 2.
[Switching to Thread -1220736080 (LWP 2152)]
0xb7cf5481 in read () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7cf5481 in read () from /lib/tls/libc.so.6
#1  0xb7d82e13 in sf_open () from /usr/lib/libsndfile.so.1
#2  0xb7d814e6 in sf_open () from /usr/lib/libsndfile.so.1
#3  0xb7d81b2a in sf_open () from /usr/lib/libsndfile.so.1
#4  0xb7dac655 in sf_open () from /usr/lib/libsndfile.so.1
#5  0xb7d7f8eb in sf_close () from /usr/lib/libsndfile.so.1
#6  0xb7d8017f in sf_open () from /usr/lib/libsndfile.so.1
#7  0x08115a91 in sndbuf_ctrl_read ()
#8  0x0805fc9c in Chuck_Instr_Func_Call_Member::execute ()
#9  0x08058df2 in Chuck_VM::compute ()
#10 0x08058ed7 in Chuck_VM::run ()
#11 0x080b3ebd in Digitalio::cb2 ()
#12 0x080c4426 in RtApiJack::callbackEvent ()
#13 0x080c45b6 in jackCallbackHandler ()
#14 0xb7ed9a59 in jack_client_close () from /usr/lib/libjack-0.100.0.so.0
#15 0xb7edd3d3 in jack_acquire_real_time_scheduling ()
   from /usr/lib/libjack-0.100.0.so.0
#16 0xb7c26cfd in start_thread () from /lib/tls/libpthread.so.0
#17 0xb7d04f1e in clone () from /lib/tls/libc.so.6

It seems every chuck program of the otf example series that loads a .wav
file makes chuck do some file access in the process callback (which
potentially blocks). otf_06.ck and others seem to get executed just
fine. I did run the tests for relatively short times though, so it might
as well happen that more pops up lateron. I will leave the otf_05
and otf_06 running all afternoon (i'll be gone for rehearsal)..

Do you have any certain example programs in mind which i could test for
RT safeness?

Have fun,
Flo


-- 
Palimm Palimm!
http://tapas.affenbande.org