7 Jan
2003
7 Jan
'03
10:13 p.m.
>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!