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

Ingo Molnar
2005-07-03T14:04:45Z

* 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