> >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. > > > >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!
Do you think the problem might be jack? Some race condition that only happens (or is much more likely to happen) in 2.4.20? It does sound more like a kernel bug, but I have not seen a hung machine without having jack and clients running... -- Fernando
