* William Weston <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |