Thanks to the Unigine Heaven demo I was finally able to reliably reproduce an issue which I only experienced with Mplayer before.
Upon switching back and forth between one window where OpenGL is used and another one, quickly the whole input and output of X freezes followed by a hard restart of my system a few moments later.
Conditions to reproduce here:
1) Have the Composite extension enabled
- the crash does not occur without the Composite extension
- disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the crashes
2) Have rencer acceleration enabled
- Setting RenderAccel to "Off" prevents the crashes
- Crashes occur both with EXA as well as XAA
3) Start an application which opens an OpenGL context with a least amount of complexity wrt the graphics
- Crash is reproducible with Mplayer using the GL video output
- Also reproducible with the Unigine Heaven demo
- Not reproducible with glxgears (seemingly too simple)
4) Open another application window and start switching back and forth between those two
Due to the hard restart I am currently unable to find any traces of debugging information so help for getting started on this is greatly appreciated.
I am aware that there are quite a few other reports which sound similar to this one and I thought about adding a comment on these. However, without any additional info to add, my comment wouldn’t be that much worth. Thus I am mostly hoping for help on gathering as much information as possible.
Aside from using the latest Mesa git master I am also using the latest git master of the xf86-video-ati DDX.
(I also wanted to spare you from this lengthy message in #dri-devel ;-) )
(In reply to comment #0)
> - disabling Compositing in my WM (Xfwm4, uses XRender) does prevent the
This should actually read "does not prevent".
Can you attach your xorg log and dmesg output?
Created attachment 46732 [details]
X.org log file
Created attachment 46733 [details]
dmesg log file
(In reply to comment #2)
> Can you attach your xorg log and dmesg output?
Here they are. I tried to make sure that everything is written to disk by running an endless loop calling "sync" but to no avail. The files contain no traces at all from a crash or the like.
Any idea how I at least could prevent the sudden reboots to be able to gather some debugging data?
Created attachment 47339 [details]
Here’s at least some output I was able to find in my kern.log. Missing memory space sure sounds odd but maybe this is finally something to get started on.
Still experiencing the same issues with revision 2f0b44f981d1715b62b189f465546d865b10d0f3 of mesa. Any idea what else I could do?