Created attachment 119860 [details] output of qdbus org.kde.KWin Hi! I'm experiencing random freezes of Plasma 5 including all running apps. The mousepointer can still be moved around but left- or right-klicking has no effect. Alt + tab or shortcuts don't work. The freezes are infrequent, perhaps once in a day or two or so, not reproducible and not related to any specific app. The session can be recovered from a virtual terminal with DISPLAY=:0 kwin_x11 --replace. "Top" shows normal CPU-usage (i.e. ~0). IIRC the freezes only happened when the compositor was OpenGL. I've switched to XRender now and will stick to it for a while. The output of qdbus org.kde.KWin /KWin supportInformation is attached. Frameworks is 5.46.0. Thanks for clues.
Nvidia card and freezing when you open the alt+tab switch? If so, it's a dupe of a known thing. Otherwise we'll need a backtrace of kwin during the freeze. See https://community.kde.org/KWin/Debugging#Debug_.26_log_KWin_.28or_any_process.29_via_gdb
(In reply to David Edmundson from comment #1) > Nvidia card and freezing when you open the alt+tab switch? > No, Intel-GPU (Ironlake) and unpredictable. > If so, it's a dupe of a known thing. Otherwise we'll need a backtrace of > kwin during the freeze. See > https://community.kde.org/KWin/Debugging#Debug_.26_log_KWin_. > 28or_any_process.29_via_gdb OK, I'll get prepared. Although I really could live without the freezes - one time I ran into it during online-banking which was a bit scary.
Short status report: I have used XRender for 5 days without any problem and after that openGL-2.0 for a week, also without problems. I have switched to openGL-3.1 now.
Created attachment 120211 [details] Stacktrace of freeze with openGL-3.1 as compositor
OK, now I caught one, while using openGL-3.1 as compositor. I have attached a stacktrace which I hope is usable. The freeze happened while the PC was unattended for a while, i. e. no input via keyboard or the mouse. The desktop was dead except for the mouse-pointer which could be moved around freely. Klicks had no effect. CPU-load was around zero. I now believe that the other freezes also happened with openGL-3.1 as compositor. I tried openGL-3.1 because I had rendering artifacts with openGL-2.0 in LibreOffice-6.0 (hw-accel. and openGL off) in some documents. XRender was always OK. So long!
New information was provided; changing status for inspection.
Caught another one, this time with openGL-2.0, see attached stacktrace. So both openGL-2 and -3 are affected. Switched to XRender now.
Created attachment 120284 [details] Stacktrace of freeze with openGL-2.0 as compositor
OK, this *could* be a driver-issue. I've learned that the Xorg-Intel-driver (20180223) that I have installed defaults to code for the SandyBridge architecture which may cause problems for the older Clarkdale/Ironlake Core i3 of the system. So I have added an /etc/X11/xorg.conf.d/20-intel.conf with the following content: Section "Device" Identifier "Intel Graphics" Driver "intel" Option "DRI" "2" # DRI3 is default #Option "AccelMethod" "sna" # default Option "AccelMethod" "uxa" # fallback EndSection With that setup the problems with openGL in LibreOffice are gone [1]. Whether this is also true for the freezes remains to be seen. I want to test that for a week or so with openGL-2.0 and will report back. [1] Writer: duplicate lines/headlines or ill-rendered fonts when scrolling; out of sync zoom of split windows in Calc
After a week of normally intense use and without freezes or other problems I'm sure now that it really *was* an unfortunate driver issue as described in my last post. So as far as I'm concerned, you may close this report. Should freezes reoccur, I would re-open it. Thanks for your time!
Thanks for the update; changing status. If possible, please also add the bug report from the Mesa/Intel bug tracker.
(In reply to Christoph Feck from comment #11) > Thanks for the update; changing status. > > If possible, please also add the bug report from the Mesa/Intel bug tracker. Given the venerable age of the systems Core i3, filing a bug report with Mesa and especially Intel wouldn't make much sense. ;) The manpage for the currently installed driver says: Option "AccelMethod" "string" Select acceleration method. There are a couple of backends available for accelerating the DDX. "UXA" (Unified Acceleration Architecture) is the mature backend that was introduced to support the GEM driver model. It is in the process of being superseded by "SNA" (Sandy‐bridge's New Acceleration). Until that process is complete, the ability to choose which backend to use remains for backwards compatibility.[...] And I found the same in the manpage for the latest driver on https://www.x.org/archive/individual/driver (xf86-video-intel-2.99.917.tar.bz2, 2014-12-21). So I guess the options to avoid the freezes with pre-Sandybridge-CPUs are probably limited to either use (even) older drivers or the method described in my earlier post. The latter one works here and AFAICT comes without performance-penalties. So long!