A GPU reset brings down kwin on the display forever. It can not reset nor re-start in compose mode nevermore. Raster mode and other compositing window managers and GL applications works on the display. The GPU seems like OK after the reset. There's no problem if no GL context on the display nor in kwin raster mode with GL context but this is uncommon nowadays. Reproducible: Always Steps to Reproduce: 1. Open http://helloracer.com/webgl/ in Firefox 2. Open http:// hunger.hu/webgl.html (WARNING: it will trigger a GPU reset on your desktop!) 3. Your desktop will probably freeze due to kwin. 4. Change to a VT, try to re-start kwin: $ kwin --replace 5. Change back to X, the new kwin will work for about 1 second then the screen will freeze again. Other composite WM's like metacity works. Kwin with KWIN_COMPOSE=N works. Expected Results: Please handle this situation well. A crafted WebGL page could be extremely annoying to KDE users now. I can't get KWin supportInformation of a frozen screen so the dump is from raster mode. Fedora 21. Intel(R) Ivybridge Desktop. GL_ARB_robustness supported.
Created attachment 90069 [details] qdbus org.kde.KWin /KWin supportInformation
Created attachment 90070 [details] glxinfo
Created attachment 90071 [details] $ strace -tt -ff kwin --replace
metacity afair uses xrender compositing (what will likely work w/ kwin as well) - Does it work again after shutting quitting firefox? - do other OpenGL applications (eg. glxgears should do for a start - or try tuxracer ;-) work along the Firefox window? - does kwin work this way: export KWIN_USE_BUFFER_AGE=0; kwin --replace & - can you please attach a supportInformation dump while compositing is active? If you want to do that from VT1: export `tr '\0' '\n' < /proc/$(pidof kwin)/environ | grep DBUS_SESSION_BUS_ADDRESS` qdbus org.kde.KWin /KWin supportInformation
Wow, thanks for the very quick reply. :) (In reply to Thomas Lübking from comment #4) > metacity afair uses xrender compositing (what will likely work w/ kwin as > well) So I was wrong. Now I tried to start compiz on this screen and it also does not work (shows a blank screen). Seems like _all_ compositing WM's are affected after the GPU reset, not just kwin. > - Does it work again after shutting quitting firefox? No, kwin (and compiz) can not restart in compose mode even if all windows are closed. > - does kwin work this way: > export KWIN_USE_BUFFER_AGE=0; kwin --replace & No, does not work. > - do other OpenGL applications (eg. glxgears should do for a start - or try > tuxracer ;-) work along the Firefox window? > - can you please attach a supportInformation dump while compositing is > active? > If you want to do that from VT1: > export `tr '\0' '\n' < /proc/$(pidof kwin)/environ | grep > DBUS_SESSION_BUS_ADDRESS` > qdbus org.kde.KWin /KWin supportInformation I started a new X session (logout/login) and I can not reproduce this problem in this session - kwin handles the GPU reset well, even with many GL windows. I have reproduced it 4 times in a row before, but something has changed now. I'll be back after I figured out what's going on here. I'll test compiz too because I doubt now that it's a kwin problem..
(In reply to Roland Pallai from comment #5) > I started a new X session (logout/login) and I can not reproduce this > problem in this session - kwin handles the GPU reset well, even with many GL > windows. > > I have reproduced it 4 times in a row before, but something has changed now. > I'll be back after I figured out what's going on here. I'll test compiz too > because I doubt now that it's a kwin problem.. I had automatic Mesa upgrade from 10.3.5 to 10.4.0 just a few hours ago. My last X session is the first that uses this new Mesa. Seems like this problem has been fixed by the new Mesa. I'll do some stress test tomorrow, anyway. [root@dh log]# grep mesa yum.log Dec 20 23:27:05 Updated: mesa-libglapi-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:07 Updated: mesa-libGL-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:08 Updated: mesa-libgbm-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:08 Updated: mesa-libEGL-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:08 Updated: mesa-filesystem-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:09 Updated: mesa-filesystem-10.4.0-1.20141214.fc21.i686 Dec 20 23:27:10 Updated: mesa-dri-drivers-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:10 Updated: mesa-libEGL-devel-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:11 Updated: mesa-libGL-devel-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:12 Updated: mesa-libxatracker-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:13 Updated: mesa-libGLES-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:14 Updated: mesa-libwayland-egl-10.4.0-1.20141214.fc21.x86_64 Dec 20 23:27:16 Updated: mesa-libglapi-10.4.0-1.20141214.fc21.i686 Dec 20 23:27:16 Updated: mesa-libgbm-10.4.0-1.20141214.fc21.i686 Dec 20 23:27:16 Updated: mesa-libEGL-10.4.0-1.20141214.fc21.i686 Dec 20 23:27:18 Updated: mesa-libEGL-devel-10.4.0-1.20141214.fc21.i686 Dec 20 23:27:19 Updated: mesa-dri-drivers-10.4.0-1.20141214.fc21.i686 Dec 20 23:27:19 Updated: mesa-libGL-10.4.0-1.20141214.fc21.i686 [...] If all my issues has been solved so fast I'd be a happy man. :) Thanks!
setting to upstream as it seemed to have been a driver issue.