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

William Weston
2005-07-02T01:47:52Z

On Fri, 1 Jul 2005, Ingo Molnar wrote:

> oops - i had it in my tree (so all my tests passed), but it escaped the
> -39 patch. I've uploaded -50-40 with this included too.

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

All of this behavior is 100% reproduceable on recent realtime SMP/SMT
kernels, and is _not_ seen with vanilla SMP/SMT, Fedora SMP, or realtime
UP kernels. I'll be running realtime UP kernels on this Xeon/HT box for a
while unless someone gives me reason to enable SMT again.

You can tell me to shut up now.... at least until I decide to hunt down
another corner case ;-}

Best Regards,
--William Weston