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: Sat Jan 04 2003 - 01:07:35 EET
[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
This archive was generated by hypermail 2b28 : Sat Jan 04 2003 - 01:10:28 EET