I did test with a few other versions of config, patchset and kernel sources but keep running into problems. I can't seem to be able to produce something that works reliably, all of the kernels run around 30 to 45 minutes with around 65 - 70% load on jackd and then hard lock. Since this machine I am using is pretty new, and I am havn't really run rt-linux on this one extensivly yet (partly because its almost not necessary with current stock debian kernels anymore), it could be something about the hardware, although it seems unlikely. Its a T61 T5500 with 1G Ram fwiw. With this in mind I think I should ask for some advice on what people consider sane values for important scripts, pam etc. My /etc/security/limits.conf looks like this:

@audio - rtprio 99
@audio - nice -15
@audio - memlock 1024000000

What values do people use, and why? Are these sane values? I remember that realtime-lsm did something more brutal than this, so I would find it hard to see how this could be the reason. What are the rtirq settings that are considered safe? For now, I switched it off, yet I can see how it could be useful/necessary for certain setups, and don't want to rule it out completely. I start jackd oh hw:1 (hdsp multiface) with the following parameters:

/usr/bin/jackd -R -P89 -m -dalsa -dhw:1 -r48000 -p128 -n2 -Xseq

This works really well with SuperCollider 3 doing quite a lot of synthesis... well... until it locks up the machine. Could it be the Interrupt-sharing particular to my machine? I see that yenta sits on an interrupt together with uhci (usb?) and my graphics card (Intel  graphics chipset DRM). Do people tend to switch ACPI off anymore, like it is being recommended for certain setups on the RT-wiki?
Last, but not least: my version of gcc is 4.3.1-2 (Debian). I briefly thought this could be the source of the problem, but obviously have hardly a way to test that, except for building a kernel on a different OS. hmmmmm, I'm getting frustrated with this, need some advice and success to keep me going.... :)

bbfn

karsten