[brief description of problem: jack + several other jack clients + disk activity - a tar process, for example - hangs the machine]
> This is what I'm currently testing: > > 2.4.20 + capabilities + preempt + lowlat + > [from Con Koliva's page] > Read latency2 disk hack (Andrew Morton) + ACPI + variable HZ (1000) + > [from an older jl patch] > drm low latency + > [from ext3 page] > ext3 patches for 2.4.20 > > I built the icebox kernel debugger to try to get some info on where the > program is hanging and this is what I get in terms of what's happening > (four instances of breaking into the debugger with the Sysrq-d key), > this is the list of tasks: > > 4) [other 3 erased for brevity] > schedule +1ab > sleep_on +45 > bread +20 > __mark_inode_dirty +d9 > pipe_write +1b9 > poll_freewait +44 > sys_write +9f > system_call +33 > > So the system seems to be stuck in __mark_inode_dirty 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? -- Fernando