Subject: Re: [linux-audio-user] MusE Race Condition
From: Christian Henz (chrhenz_AT_gmx.de)
Date: Fri Aug 06 2004 - 11:54:25 EEST
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."
This archive was generated by hypermail 2b28 : Fri Aug 06 2004 - 11:59:25 EEST