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.
