Messages in this thread | | | Date | Sun, 3 Jul 2005 16:04:32 +0200 | From | Ingo Molnar <> | Subject | Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24 |
| |
* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |