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

[Fernando Pablo Lopez-Lezcano]

> > > 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. 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.
> > 
> > Is this only happening with ecasound? (and only with two copies running
> > at the same time?) Or do you see the problem with other jack software as
> > well?
> 
> no, I managed to crash it a couple of times before, while using a
> arecord and jackrec simultaneously. When that happened, jackrec and
> arecord were being run without privilieges, but jackd was running with
> the "-R" (realtime) switch

That is strange. You should not be able to run arecord and jackrec at
the same time. Jackd monopolizes the alsa device so arecord should find
it busy (and eventually timeout?). 

When you run jackd with -R all jack clients get a thread that runs with
realtime priority (that is automatic). So in your case both jackd and
the audio thread of jackrec were running SCHED_FIFO. 

Roger Larsson sent me a small app to monitor SCHED_FIFO processes and
downgrade them to normal schedulling when they start eating all the cpu
for a (programmable) time. It was very useful when I was having lock up
problems (in that case due to a problem in ext3). The machine would lock
up for 5 seconds and then magically I would get control again :-) I'm
adding the files as attachments to this email. 

> > > It still responds to pings but nothing else. I am running with low-latency
> > > on. The system is remote, so it's sort of a pain to test out different
> > > configurations.
> > 
> > Yuck. It sounds like an infinite loop on a SCHED_FIFO process (ie:
> > anything interrupt related may work but no processes get to be
> > schedulled at all other than the realtime process sucking up all cpu
> > cycles). But you mention that it also happens when you run as a normal
> > users with no special privileges so that should not be the problem. 
> 
> no, something has to be running with priviliges. In the case I
> described, jackd was running un-priviliged, 

Meaning as root but without "-R"?

> but both ecasound sessions were running as root.
> 
> > Of course, as you say, it could also be alsa...
> 
> possibly. there is a fix regarding spinlocks that went into alsa CVS on
> April 26th. Don't know if that fix made it into 0.9.3 or not. 

The current Planet CCRMA alsa packages are from CVS, dated April 9th...

> While my
> system is UP, doesn't preempt use spinlocks? Does 2.4.20-4.ll.acpi have
> preempt enabled?

Yes. 
-- Fernando

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: text/x-makefile
Size: 66 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20030514/1ac5c441/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rt.c
Type: text/x-c
Size: 3162 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20030514/1ac5c441/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rt_monitor.c
Type: text/x-c
Size: 9868 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/planetccrma/attachments/20030514/1ac5c441/attachment-0002.bin>