Subject: Re: [Jackit-devel] Re: [linux-audio-dev] 2.4.20 + lowlat +preempt + alsa + jack = dead computer
From: Fernando Pablo Lopez-Lezcano (nando_AT_ccrma.Stanford.EDU)
Date: Wed Jan 08 2003 - 04:07:27 EET
> >I browsed the Kernel Source and there is only one mark_inode_dirty in
> >pipe_write (in fs/pipe.c). So we know where it is hanging...
> >
> >And in __mark_inode_dirty (in fs/inode.c) there is one
> > spin_lock(&inode_lock)
> >call, and I guess that is where the whole thing is hanging. So something
> >is holding that lock... how do I find out who is doing that? Apparently
> >the handling of inode_lock is confined to inode.c. I'll keep reading.
[Andrew Morton had suggested that the stack traces did not show problems
with stuck locks in the kernel...]
> >Maybe the pipe in question is one of the pipes that jack uses for ipc?
>
> seems *damn* likely ... sorry to just be chiming in with a useless comment!
One more (small) datapoint. Roger Larsson sent me off the list a couple
of small utilities (VERY nice tools!) that monitors the cpu usage of
SCHED_FIFO processes and after a timeout actually downgrades the
persistent hogs to SCHED_OTHER.
So I run that in a terminal and after playing around with a bunch of
jack apps got the machine to lockup... and then, after a little bit,
suddenly, it came back to life! (you could see that the monitor had
changed the priority of the hogs to SCHED_OTHER).
So I guess that somehow jack has a hard to trigger race condition that
locks up the machine when running SCHED_FIFO.
Now I have to figure out how to trace the thing so as to determine where
the whole thing is locking. Help from the jack gurus appreciated.
-- Fernando
This archive was generated by hypermail 2b28 : Wed Jan 08 2003 - 04:09:21 EET