> >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