4 Jan
2003
4 Jan
'03
5:55 a.m.
Fernando Pablo Lopez-Lezcano wrote:
...
4)
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, whatever that is.
No, that's just stack gunk.
There's no sign of a deadlock or a livelock in these traces. It just
looks like these tasks are asleep and not waking up.
Each time I break into the debugger I see one of the
jack related
processes as the current process. No other processes, so I assume the
SCHED_FIFO ring is still running but everything else is being blocked by
the mark_inode_dirty call.
Why do we not believe that this is an application bug? If the
SCHED_FIFO application is stuck in a loop, dead box. And if "jack"
is always the running process, that appears to be the case.
Try running jack without SCHED_FIFO.
Give yourself a SCHED_FIFO shell (hiher priority than jack) so
that you can still poke around and run ps and things. See if
`jack' is consuming 100% of CPU. There's a little proggy called
`run_rr' in http://www.zip.com.au/~akpm/linux/zc.tar.gz which
will give you a SCHED_RR shell.