[linux-audio-user] MusE Race Condition

[Christian Henz]

On Fri, Aug 06, 2004 at 05:48:30PM +1000, Erik de Castro Lopo wrote:
> On Thu, 05 Aug 2004 23:04:49 -0700
> davidrclark at earthlink.net wrote:
> 
> > I found that I can set ulimit -l to some fraction of memory so that
> > it isn't "unlimited."  This does produce various warnings, but on this
> > machine, with what little I've done thus far, MusE *seems* to run OK.
> > It would seem to me, with what little I know about mlock() policy, that
> > there is an mlock() SNAFU in some of the Linux audio programs.  If 
> > that's not the case, I'd really like to hear the explanation.  (Thanks
> > to anyone who contributes info on this.)
> 

The deadly combination seems to be Linux 2.6.x, jackd in realtime mode, a Qt-based jack client and a Radeon card with DRI driver. Paul once explained that this is about mlock and video ram. (http://eca.cx/lad/2004/02/0145.html)

The problem doesn't come up with:

- Linux 2.4.x 
- Linux 2.6.x, X with DRI disabled
- Linux 2.6.x, jackd with out -R
- Linux 2.6.x, jackd with -R AND -m
- Linux 2.6.x, jackd with -R and only non-Qt clients

I've been having this problem forever, but before only the Qt clients would
freeze in addition to ps, top, killall also freezing on execution. I just 
tried it again, and now my whole system freezes too! Using ulimit didn't help 
at all for me. (I tried with 'ulimit -l 131072' for a 128MB limit on my 256MB
- the argument is supposed to be in KB, right?)

Older reports:

http://sourceforge.net/mailarchive/message.php?msg_id=7005966
http://sourceforge.net/mailarchive/message.php?msg_id=7009864
http://sourceforge.net/mailarchive/message.php?msg_id=8887324

cheers,
Christian

-- 
"Somewhere in Texas... a village is missing its idiot."