Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24

[Ingo Molnar <mingo@elte.hu>]

* William Weston <weston@sysex.net> wrote:

> FWIW, I'm still seeing the SMT scheduling? meltdown issues with 
> -50-42.  Running two instances of 'dd if=/dev/zero of=/dev/null 
> bs=65536' instead of 'burnP6' results in the same behavior.  Here's a 
> quick recap:
> 
> - Start (or login to ) X.
> - Start an X app that constantly updates the screen, like wmcube, or vlc.
> - Run 'burnP6' or 'dd if=/dev/zero of=/dev/null bs=65536'.
> - Run trace-it.  Trace completes without any troubles.
> - Run another 'burnP6' or 'dd if=/dev/zero of=/dev/null bs=65536'.
> 
> At this point, most of the system is unresponsive:
> 
> - Most X apps are frozen (even top in its own xterm).
> - Mouse lost synchro serio warnings show up on serial console.
> - Serial console is otherwise unresponsive (no SysRq).
> - X server quits responding to keyboard input.
> - Kbd input makes mouse temporarily unresponsive (for .1 to >5 secs).
> - Mouse immediately after kbd triggers more 'mouse lost synchro' messages.
> - Networking is lost (box won't respond to pings).
> - Any script automating starting burnP6 or dd and then trace-it hangs.
> 
> A few things are left working (but not enough to get the system back):
> 
> - Mouse pointer (movements are chunky) and window focus.
> - Mouse scroll wheel can still scroll xterms and switch workspaces.
> - SysRq-B

hm, i can reproduce a variant of this, by starting enough 'dd' tasks.  
(it needed more than two on a 2-way/4-way HT testbox though) Indeed 
everything seems to be starved, but SysRq still worked so i was able to 
SysRq-kIll all tasks and thus the system recovered.

i'm debugging this now.

	Ingo