Well, the boxen with Intel i915 chips scramble the video after a period of time somehow relating to the amount of graphic activity with log entries: Dec 26 21:05:04 blade17 kernel: [521008.703090] [drm] stuck on render ring Dec 26 21:05:04 blade17 kernel: [521008.708996] [drm] GPU HANG: ecode 3:0:0x6affbfc1, in X [23010], reason: Ring hung, action: reset Dec 26 21:05:04 blade17 kernel: [521008.730173] drm/i915: Resetting chip after gpu hang Dec 26 22:39:55 blade17 dbus[975]: [system] Activating service name='org.freedesktop.problems' (using servicehelper) Dec 26 22:39:55 blade17 dbus[975]: [system] Successfully activated service 'org.freedesktop.problems' in /var/log/messages. This is related to a known bug in the Xorg driver for i915's which appeared in June in an update to Xorg and does not appear to be resolved. The Matrox systems don't have that same issue. The display just goes dark until killed using a ssh login. Common symptom is the creation of lots of committed buffers until the built-in fault detector in X notices there is no more memory available and crashes the systems. Munin graphs show a sawtooth of committed memory on the systems that crash. A possible fix is to revert to a previous version of Xorg, which should cure the problem until/if someone gets around to fixing it. The other alternate that works is just not to monitor the units with a KVM switch, but remote monitoring using ssh on a PC is not my favorite choice.