On two blades both with Atom Processors but different Graphics chips (a Matrox WPCM450 on one, Intel 82945Gon the other). One machine had distorted video and required logging out of KDE and then back again. The other one had no video and required ssh from another box to restart X remotely (which I didn't think I should be able to do). Does anyone else see problems with KDE ( or X) after the upgrade? I'm not getting any obvious error messages, but my gut level says it is a problem with X rather than KDE. I haven't had the time to troubleshoot this properly, but when (if) it happens tomorrow I will see what I can find.
On 12/16/2015 03:53 PM, pro alias wrote:> On two blades both with Atom Processors but different Graphics chips (a > Matrox WPCM450 on one, Intel 82945Gon the other). One machine had distorted > video and required logging out of KDE and then back again. The other one > had no video and required ssh from another box to restart X remotely (which > I didn't think I should be able to do). > > Does anyone else see problems with KDE ( or X) after the upgrade? I'm not > getting any obvious error messages, but my gut level says it is a problem > with X rather than KDE. I haven't had the time to troubleshoot this > properly, but when (if) it happens tomorrow I will see what I can find.This update set (if you were not using the CR repo before) performed an upgrade from CentOS-7.1.1503 to CentOS-7.2.1511 .. which included a rebase of KDE from 4.10 to 4.14 and Xorg from 1.15 to 1.17 .. it also included a kernel upgrade which requires a reboot. Restarting X would definitely be required. So, if after the restart things are working then that is to be expected. I would reboot after the major update if at all possible. Thanks Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20151216/25a45bc7/attachment-0001.sig>
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.