> > this will produce reams of output, but will provide you with the next
> > hint.
>
> reams of output collected...
>
> > problem: the output will affect scheduling, which might make the
> > problem go away. i recommend outputting it to a file if possible, and
> > viewing after the fact.
>
> I
On Tue, 2003-01-07 at 19:14, Paul Davis wrote:
> >> what do you want to know?
> >
> >Ahem, everything? :-) ;-) :-)
>
> recompile with DEBUG_ENABLED defined at the top of engine.c and then
> if necessary client.c as well.
>
> this will produce reams of output, but will provide you with the next
>
> > > what do you want to know?
> >
> >Ahem, everything? :-) ;-) :-)
>
> recompile with DEBUG_ENABLED defined at the top of engine.c and then
> if necessary client.c as well.
There is a missing ";" in line 544 of libjack/client.c that triggers a
build error if debugging is enabled.
Correct lin
On Wednesday 08 January 2003 03:34, Paul Davis wrote:
> >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
>> what do you want to know?
>
>Ahem, everything? :-) ;-) :-)
recompile with DEBUG_ENABLED defined at the top of engine.c and then
if necessary client.c as well.
this will produce reams of output, but will provide you with the next
hint. problem: the output will affect scheduling, which might ma
> >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
>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
> >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 som
> >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 som
>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 h
[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
11 matches
Mail list logo
