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