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 line is:
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 have big
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
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 hard
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
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 make
[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 +
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
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
