7 Jan
2003
7 Jan
'03
11:30 p.m.
On Wednesday 08 January 2003 03:34, Paul Davis wrote:
Thinking about it...
It could mark the processes that was in the run queue when the
monitor kicked in.
Maybe it should only reduce the priority of those/that as a first level.
And if that did not work - reduce all...
But I am a little afraid of adding features in this kind of application...
Tomorrow... for now I send the current version... (it is quite small)
Start rt_monitor as root from a text terminal (Alt-Ctrl-F1)
/RogerL
-
Roger Larsson
Skellefteå
Sweden
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 to trigger race condition that
locks up the machine when running SCHED_FIFO.
Now I have to figure out how to trace the thing so as to determine where
the whole thing is locking. Help from the jack gurus appreciated.
what do you want to know? can you get roger's tool to tell you which
process (PID) is hogging the CPU? is it jackd or a client?