[lkml]   [2004]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U8

* Rui Nuno Capela <> wrote:

> The fact is jackd -R (realtime mode; SCHED_FIFO) hosing the system,
> and thats exposed as soon as some jack audio client application enters
> into the chain.
> Running jackd non-realtime (SCHED_OTHER) does not expose this problem,
> so I think it's a scheduling related one.

i tried to pole jackd a little bit (just using things like
jack_freewheel and jack_impulse_grabber - i dont even know what they
do), and got jackd into some sort of userspace loop:

2558 root 16 0 27900 1852 2152 S 97.8 0.8 2:36.38 jackd

attaching gdb to it shows:

Loaded symbols for /usr/local/lib/jack/
0xffffe410 in ?? ()
(gdb) bt
#0 0xffffe410 in ?? ()
#1 0xbffff7f8 in ?? ()
#2 0x00000a67 in ?? ()
#3 0x00000000 in ?? ()
#4 0x4db8adf8 in pthread_join () from /lib/tls/
#5 0xb77d6e66 in oss_driver_stop (driver=0x8055938) at oss_driver.c:696
#6 0x0804ba03 in jack_engine_delete (engine=0x805c308) at engine.c:2466
#7 0x0804ade7 in main (argc=3, argv=0xbffffb44) at jackd.c:207

it's looping somewhere in the pthread code, and it does no system-calls
at all and thus no scheduling as well.

i dont know much about jackit, and it could easily be that something in
this kernel broke its interaction with pthread, but it seems to me that
this loop is in userspace and is only 'fatal' if the looping thread runs
at SCHED_FIFO priority. Could someone with more jackit experience try to
figure out what's going on here?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.581 / U:1.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site