![]() | |||||||||||||
Messages in this thread |
* 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/ | ||||||||||||
| Last update: 2005-07-03 16:10 [W:0.592 / U:0.290 seconds] ©2003-2008 Jasper Spaans | |||||||||||||