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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
