[PlanetCCRMA] guaranteed deadlock w/ 2.4.20-4.ll.acpi

[Rui Nuno Capela]

I'll report a similar issue,

> I am running redhat 8.0 with kernel-2.4.20-4.ll.acpi, jack-0.7.x (tried
> 0.70.. and the freshly updated 0.71..) and ecasound. Filesystems are all
> ext3.

In my lab machine I have all this, but everything is compiled from source
(not from planetccrma rpms). The kernel there is the latest from  stock,
2.4.21-rc1 with all the vaery same planetccrma's-core patches
(low-letency, preemptble, variable-hz, capabilities, etc).

> Even when I run jack without the "-R" switch and as an unpriviliged
> user, using 2 simultaneous sessions of ecasound to record (ecasound -t:60
> -i:jack_alsa -G:jack,ecasound_rec1,streaming -o stdout) as root with or
> without the "-r" switch, my system will deadlock reliably and immeadiatly.
> It still responds to pings but nothing else.

The alsa-driver's are also built from source (from
http://www.alsa-project.org). What makes me on topic is that I've recently
experienced very similar total system lockups when the 0.9.3a drivers were
in place. With the 0.9.2 ones everything works great as before.

And the issue is NOT kinda probabilistic: the system ALWAYS freezed
completely whenever the jackd daemon is fired up. The only solution was in
backup to alsa-driver-0.9.2, after some bitter griefs :)

> I am running with low-latency on. The system is remote, so it's sort of
> a pain to test out different configurations. Has anyone else seen this?
> I'd like to try with another kernel, but haven't gotten around to it
yet. > Could it be the version of alsa? my alsa is the latest one from
> planet-ccrma.

In my case, the latest alsa-drivers were surely the ones to blame. Don't
know if this helps you (didn't check what are the planetccrma's latest
alsa drivers version). On my production machine, a planetccrma RH8 machine
as yours, I'm sure I'm using 0.9.1 without any pain.

All my filesystems are ext3 too.

-- 
rncbc aka Rui Nuno Capela