Hi On Tues Nov 22 I wrote: > I've recently moved a system over to Slackware 10.2 which utilises NPTL and > I'm aware of the issues NPTL has raised in the past. Based on a comment on > the Jack website though I sort of assumed that things were now in hand and > that Jack had a workaround in place for the issue. > > Despite this I have found that jackd itself (when run using set_rtlimits) > gives an error (-11, EAGAIN) when "creating realtime thread".
I have since discovered (thanks to strace) that the problem lies in an mmap2() call which requests a size of around 8MB. It appears to be part of the NPTL pthread_create() function. The error returned by mmap2() (EAGAIN) indicates either a locked file or "too much locked memory" (according to the manpage). Because this is an anonymous map the problem must have been the latter. Increasing the "locked memory" limit from 20MB to 40MB made jackd start without having to resort to the LD_ASSUME_KERNEL hack. Another problem then surfaced: with jackd running under NPTL, jack applications using NPTL (eg: ardour) suddenly started to require all of their memory to be lockable. For ardour with a large session this can get quite large (I saw 130MB at one point last night). So, with jackd running with LD_ASSUME_KERNEL = 2.4.19 and a memlock limit of 20MB everything worked and ardour (with NPTL - ie: without LD_ASSUME_KERNEL) was obviously not trying to lock excessive amounts of memory. With jackd running with NPTL and a large enough memlock limit things work but jack clients appear to require much more memory be locked. One thing I will try next is recompiling ardour; perhaps there's something funny there. In any case though, does any of this ring a bell with anyone? Regards jonathan
