https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #1 from Eugene Shalygin eugene.shalygin@gmail.com --- This happens only when kwin starts for the first time. There are no crashes at next runs.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #3 from Eugene Shalygin eugene.shalygin@gmail.com --- With "glamor" as acceleration method, these crashes are much more rare

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #5 from Knut Andre Tidemann knut.tidemann@gmail.com --- I forgot to add:

My card is a Radeon HD 5670

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #7 from Eugene Shalygin eugene.shalygin@gmail.com --- it is quite interesting to note that the crash happens only using 1920x1080 and higher screen resolution. If the resolution is lower, kwin works fine.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #9 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #8)

I don't have a usable backtrace at hand, but I'm seeing very similar crashes in gnome-shell as well with Mesa 9.1 and Linux 3.8.3. With Mesa 9.0.3, I haven't noticed any crashes so far. It crashes much more frequently with two monitors (both 1920x1200) attached than with just one.

Can you bisect mesa?

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #11 from Michael Mair-Keimberger bu9zilla@gmail.com --- I don't know if its the same but i can confirm similar crashes.

First of all, i have a triple head setup, 2 screens with 1920x1200 (left and right) and one with 2560x1600 (middle). Those crashes happen since kernel 3.8 (i've used 3.8.[1-4]) and mesa-9.1 but i don't know which one actually introduced the problem as i both updated at the same time.. Furthermore they are no crashes at all if i disable desktop effects in kde.

Basically i only have to create an new user and login into it. Kde usually sets the resolution of all screens to 1920x1200 with enabled desktop effect. I can actually move the screens back and forth (because the ordering is wrong too with the first start) without problems, but as soon as i'm changing the resolution of the middle screen X crashes. Without effects i won't get any crashes.

If you need more info, please let me know.

Below are the relevant parts of Xorg.0.log (even though without debug symbols i think its quite useless ;) ):

[ 1671.397] (EE) [ 1671.397] (EE) Backtrace: [ 1671.397] (EE) 0: /usr/bin/X (xorg_backtrace+0x36) [0x5860f6] [ 1671.397] (EE) 1: /usr/bin/X (0x400000+0x189e09) [0x589e09] [ 1671.397] (EE) 2: /lib64/libpthread.so.0 (0x7ff6d65e0000+0x10ff0) [0x7ff6d65f0ff0] [ 1671.397] (EE) 3: /lib64/libc.so.6 (0x7ff6d5238000+0x8a6fb) [0x7ff6d52c26fb] [ 1671.397] (EE) 4: /usr/lib64/dri/r600_dri.so (0x7ff6d2438000+0x5175c7) [0x7ff6d294f5c7] [ 1671.397] (EE) 5: /usr/lib64/dri/r600_dri.so (0x7ff6d2438000+0x517a87) [0x7ff6d294fa87] [ 1671.398] (EE) 6: /usr/lib64/dri/r600_dri.so (0x7ff6d2438000+0x52a0dd) [0x7ff6d29620dd] [ 1671.398] (EE) 7: /usr/lib64/dri/r600_dri.so (0x7ff6d2438000+0x528c4d) [0x7ff6d2960c4d] [ 1671.398] (EE) 8: /usr/lib64/dri/r600_dri.so (0x7ff6d2438000+0x528e86) [0x7ff6d2960e86] [ 1671.398] (EE) 9: /usr/lib64/xorg/modules/extensions/libglx.so (0x7ff6d44d8000+0x4541a) [0x7ff6d451d41a] [ 1671.398] (EE) 10: /usr/lib64/xorg/modules/extensions/libglx.so (0x7ff6d44d8000+0x39941) [0x7ff6d4511941] [ 1671.398] (EE) 11: /usr/lib64/xorg/modules/extensions/libglx.so (0x7ff6d44d8000+0x3a183) [0x7ff6d4512183] [ 1671.398] (EE) 12: /usr/lib64/xorg/modules/extensions/libglx.so (0x7ff6d44d8000+0x3c73e) [0x7ff6d451473e] [ 1671.398] (EE) 13: /usr/bin/X (0x400000+0x3ad96) [0x43ad96] [ 1671.398] (EE) 14: /usr/bin/X (0x400000+0x29e8d) [0x429e8d] [ 1671.398] (EE) 15: /lib64/libc.so.6 (__libc_start_main+0xed) [0x7ff6d525c94d] [ 1671.398] (EE) 16: /usr/bin/X (0x400000+0x2a1fd) [0x42a1fd] [ 1671.398] (EE) [ 1671.398] (EE) Bus error at address 0x7ff6ccbee000 [ 1671.398] Fatal server error: [ 1671.398] Caught signal 7 (Bus error). Server aborting [ 1671.398] [ 1671.398] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 1671.398] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 1671.398] (EE) [ 1671.398] (II) AIGLX: Suspending AIGLX clients for VT switch [ 1671.460] Server terminated with error (1). Closing log file.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #13 from Michel Dänzer michel@daenzer.net --- Eugene and Knut, in the future please always include information about which signal was generated, at least if it's not SIGSEGV (which is the most common).

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #15 from Eugene Shalygin eugene.shalygin@gmail.com --- (In reply to comment #14) Also tried both suggestions. Both changes together allows me to run `kwin --replace` with active kwin_gles. However, when I connect a second screen, it crashes (signal 7) with the same backtrace. When I toggle desktop effects, it crashes also.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

D. Hugh Redelmeier hugh@mimosa.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |hugh@mimosa.com

--- Comment #17 from D. Hugh Redelmeier hugh@mimosa.com --- I think that I am hitting this bug on Fedora 18 x86-64 with all current updates (as of a couple of days ago).

I'm hitting it in Gnome_shell (

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #19 from D. Hugh Redelmeier hugh@mimosa.com --- More information about my Fedora 18 x86-64 configuration:

- a single monitor: 2560 x 1600 pixels

- video card: Radeon HD 3600 XT (according to Xorg.0.log)

- Fedora's kernel: kernel-3.8.4-202.fc18.x86_64

- Fedora's mesa:

mesa-debuginfo-9.1-3.fc18.x86_64 mesa-dri-drivers-9.1-3.fc18.x86_64 mesa-dri-filesystem-9.1-3.fc18.x86_64 mesa-libEGL-9.1-3.fc18.x86_64 mesa-libgbm-9.1-3.fc18.x86_64 mesa-libGL-9.1-3.fc18.x86_64 mesa-libglapi-9.1-3.fc18.x86_64 mesa-libGLU-9.0.0-1.fc18.x86_64 mesa-libGLU-debuginfo-9.0.0-1.fc18.x86_64 mesa-libxatracker-9.1-3.fc18.x86_64

I didn't have this problem when running Fedora 17. But I did have a bit of oddness: https://bugzilla.kernel.org/show_bug.cgi?id=49981#c5

Is anything else of interest?

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #21 from korgens@yandex.com --- I can also confirm this bug.

Software: Archlinux standard installation. Linux 3.8.4-1-ARCH #1 SMP PREEMPT Wed Mar 20 22:10:25 CET 2013 x86_64 GNU/Linux KDE: 4.10.1 (no widgets, other than the task panel) Kwin: 4.10.1 (standard OpenGL effects installed) Org X Server 1.14.0 Release Date: 2013-03-05 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.8.2-1-ARCH x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=xyz ro init=/usr/lib/systemd/systemd Build Date: 09 March 2013 11:43:05AM Current version of pixman: 0.28.2 mesa: 9.1.1-1 (standard Arch package)

I also tried a git version from AUR repository (same crashes): OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 3.0 Mesa 9.2.0 (git-135bb3c) OpenGL shading language version string: 1.30 Driver: R600G GPU class: R700 OpenGL version: 3.0 GLSL version: 1.30 Mesa version: 9.2 X server version: 1.14 Linux kernel version: 3.8.4 Direct rendering: yes Requires strict binding: no GLSL shaders: yes Texture NPOT support: yes Virtual Machine: no Application::crashHandler() called with signal 7; recent crashes: 1

Xorg.conf: empty

Hardware: Intel i7 920 ATI RV790 [Radeon HD 4890] 1GB VRAM

Monitor 1: 1920x1200 (DVI) - image as background Monitor 2: 1920x1080 (HDMI) - image as background Two virtual desktops configured.

How to reproduce: just log in into KDM. When the standard KDE desktop is displayed the first Kwin crash (caused by r600 crash) has occurred and its errors is already being displayed. Kwin is re-spawned and everything seems to be normal for some minutes. Then it crashes again and then again, and again until kwin and the desktop are dead definitively.

It doesn't seem to matter what applications are being used or if the second monitor is on or off. The crashes happens all the same.

I didn't try to downgrade either the kernel or xorg, but I'm sure those crashes started to happen after the latest kernel upgrade to 3.8.x.

Here is the backtrace, which seems to confirm the general suspicion of a texture-handling problem:

Thread 1 (Thread 0x7fb64bdb6780 (LWP 734)): [KCrash Handler] #5 0x00007fb64b59859b in __memset_sse2 () from /usr/lib/libc.so.6 #6 0x00007fb59a42b40a in r600_texture_create_object () from /usr/lib/xorg/modules/dri/r600_dri.so #7 0x00007fb59a42b6e7 in r600_texture_create () from /usr/lib/xorg/modules/dri/r600_dri.so #8 0x00007fb59a43fbb5 in dri2_allocate_textures () from /usr/lib/xorg/modules/dri/r600_dri.so #9 0x00007fb59a43e695 in dri_st_framebuffer_validate () from /usr/lib/xorg/modules/dri/r600_dri.so #10 0x00007fb59a43e8ce in dri_set_tex_buffer2 () from /usr/lib/xorg/modules/dri/r600_dri.so #11 0x00007fb64b989343 in KWin::GlxTexture::loadTexture(unsigned long const&, QSize const&, int) () from /usr/lib/libkdeinit4_kwin.so #12 0x00007fb64b9810f5 in KWin::SceneOpenGL::Window::bindTexture() () from /usr/lib/libkdeinit4_kwin.so #13 0x00007fb64b987a0e in KWin::SceneOpenGL::Window::performPaint(int, QRegion, KWin::WindowPaintData) () from /usr/lib/libkdeinit4_kwin.so #14 0x00007fb64b9804bf in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #15 0x00007fb64b98065d in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #16 0x00007fb64b994275 in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #17 0x00007fb64b9738ea in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #18 0x00007fb64b994517 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #19 0x00007fb64b9764ad in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) () from /usr/lib/libkdeinit4_kwin.so #20 0x00007fb64b9757df in KWin::Scene::paintSimpleScreen(int, QRegion) () from /usr/lib/libkdeinit4_kwin.so #21 0x00007fb64b97382e in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib/libkdeinit4_kwin.so #22 0x00007fb64b9946e0 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib/libkdeinit4_kwin.so #23 0x00007fb64b974bc8 in KWin::Scene::paintScreen(int*, QRegion*) () from /usr/lib/libkdeinit4_kwin.so #24 0x00007fb64b983f4e in KWin::SceneOpenGL::paint(QRegion, QListKWin::Toplevel*) () from /usr/lib/libkdeinit4_kwin.so #25 0x00007fb64b96efcc in KWin::Compositor::performCompositing() () from /usr/lib/libkdeinit4_kwin.so #26 0x00007fb64b96faa0 in KWin::Compositor::slotCompositingOptionsInitialized() () from /usr/lib/libkdeinit4_kwin.so #27 0x00007fb6469b8b8f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #28 0x00007fb646897487 in QFutureWatcherBase::event(QEvent*) () from /usr/lib/libQtCore.so.4 #29 0x00007fb645b3618c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #30 0x00007fb645b3a60a in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #31 0x00007fb64b0eb8c6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #32 0x00007fb6469a36ae in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #33 0x00007fb6469a7011 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4 #34 0x00007fb645bd731c in ?? () from /usr/lib/libQtGui.so.4 #35 0x00007fb6469a23ff in QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/libQtCore.so.4 #36 0x00007fb6469a2688 in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from /usr/lib/libQtCore.so.4 #37 0x00007fb6469a7328 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #38 0x00007fb64b925d9a in kdemain () from /usr/lib/libkdeinit4_kwin.so #39 0x00007fb64b532a15 in __libc_start_main () from /usr/lib/libc.so.6 #40 0x0000000000400701 in _start ()

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #23 from ogjerstad@gmail.com --- I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged by Fedora) fixes the problem.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #25 from ogjerstad@gmail.com --- Not without some instructions, I have never done that before.

And, I must admit, I also downgraded llvm-libs, mesa-dri-filesystem and mesa-libxatracker. I think I had to because of dependences.

I guess I will have to build from source in that case?

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #27 from Knut Andre Tidemann knut.tidemann@gmail.com --- I've bisected the issue to this commit:

35840ab189595b817fa8b1a1df8cc92474a7c38d st/dri: implement MSAA for GLX/DRI2 framebuffers

The only thing that was recompiled was mesa, with the following options:

--with-dri-driverdir=/usr/lib/xorg/modules/dri --with-gallium-drivers=r600,swrast --with-dri-drivers= --with-egl-platforms=drm,x11 --enable-gallium-egl --enable-shared-glapi --enable-gallium-llvm --enable-glx-tls --enable-gles1 --enable-gles2 --enable-egl --enable-dri --enable-glx --enable-xa --enable-osmesa --enable-gbm --enable-texture-float

The issue was triggered by restarting kwin (kwin --replace) between each compile and locking and unlocking the screen.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #29 from Marek Olšák maraeo@gmail.com --- r600g crashes because it's mapping a MSAA resource in order to clear the CMASK to zeros. The problem is MSAA resources occupy a lot of memory and the system is failing to map the whole resource.

The solution is easy: we should clear the CMASK and HTILE buffers using DMA or streamout and not with the CPU.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #31 from Maxim Yegorushkin maxim.yegorushkin@gmail.com --- I observe the same issue on Fedora 18 with Radeon HD 5670:

[KCrash Handler] #6 __memset_sse2 () at ../sysdeps/x86_64/memset.S:873 #7 0x00007f59a39eaff2 in memset (__len=<optimized out>, __ch=204, __dest=<optimized out>) at /usr/include/bits/string3.h:84 #8 r600_texture_create_object (screen=screen@entry=0x1f317a0, base=base@entry=0x7fff57798810, pitch_in_bytes_override=pitch_in_bytes_override@entry=0, buf=buf@entry=0x0, surface=surface@entry=0x7fff57797b10) at r600_texture.c:509 #9 0x00007f59a39eb2c7 in r600_texture_create (screen=0x1f317a0, templ=0x7fff57798810) at r600_texture.c:601 #10 0x00007f59a39fda25 in dri2_drawable_process_buffers (att_count=1, atts=0x7fff577988f0, buffer_count=1, buffers=0x1e9fe80, drawable=0x1e9ff20) at dri2.c:254 #11 dri2_allocate_textures (drawable=0x1e9ff20, statts=0x7fff577988f0, statts_count=1) at dri2.c:404 #12 0x00007f59a39fc595 in dri_st_framebuffer_validate (stfbi=<optimized out>, statts=0x7fff577988f0, count=1, out=0x0) at dri_drawable.c:81 #13 0x00007f59a39fc7ce in dri_drawable_validate_att (statt=ST_ATTACHMENT_FRONT_LEFT, drawable=0x1e9ff20) at dri_drawable.c:206 #14 dri_set_tex_buffer2 (pDRICtx=<optimized out>, target=3553, format=8409, dPriv=<optimized out>) at dri_drawable.c:220 #15 0x000000304bacb3c3 in loadTexture (depth=24, size=..., pix=<optimized out>, this=0x1ea0b70) at /usr/src/debug/kde-workspace-4.10.1/kwin/glxbackend.cpp:716 #16 KWin::GlxTexture::loadTexture (this=0x1ea0b70, pix=<optimized out>, size=..., depth=24) at /usr/src/debug/kde-workspace-4.10.1/kwin/glxbackend.cpp:658 #17 0x000000304bac30d5 in KWin::SceneOpenGL::Window::bindTexture (this=0x2184e10) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:822 #18 0x000000304bac9a8e in KWin::SceneOpenGL::Window::performPaint (this=this@entry=0x2184e10, mask=mask@entry=1, region=..., data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:931 #19 0x000000304bac249f in KWin::SceneOpenGL2::performPaintWindow (this=this@entry=0x1fc3af0, w=w@entry=0x1ef75c0, mask=mask@entry=1, region=..., data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:566 #20 0x000000304bac263d in KWin::SceneOpenGL2::finalDrawWindow (this=0x1fc3af0, w=w@entry=0x1ef75c0, mask=mask@entry=1, region=..., data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:551 #21 0x000000304bad63a5 in KWin::EffectsHandlerImpl::drawWindow (this=0x2170db0, w=w@entry=0x1ef75c0, mask=mask@entry=1, region=..., data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/effects.cpp:318 #22 0x000000304bab585a in KWin::Scene::finalPaintWindow (this=<optimized out>, w=0x1ef75c0, mask=1, region=..., data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:449 #23 0x000000304bad6627 in KWin::EffectsHandlerImpl::paintWindow (this=0x2170db0, w=0x1ef75c0, mask=mask@entry=1, region=..., data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/effects.cpp:281 #24 0x000000304bab841d in KWin::Scene::paintWindow (this=<optimized out>, w=0x2184e10, mask=1, region=..., quads=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:356 #25 0x000000304bab774f in KWin::Scene::paintSimpleScreen (this=this@entry=0x1fc3af0, orig_mask=orig_mask@entry=0, region=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:342 #26 0x000000304bab579e in KWin::Scene::finalPaintScreen (this=0x1fc3af0, mask=0, region=..., data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:186 #27 0x000000304bad67f0 in KWin::EffectsHandlerImpl::paintScreen (this=0x2170db0, mask=0, region=..., data=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/effects.cpp:254 #28 0x000000304bab6b38 in KWin::Scene::paintScreen (this=0x1fc3af0, mask=0x7fff57799444, region=0x7fff577994f0) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene.cpp:140 #29 0x000000304bac5f9e in KWin::SceneOpenGL::paint (this=0x1fc3af0, damage=..., toplevels=...) at /usr/src/debug/kde-workspace-4.10.1/kwin/scene_opengl.cpp:308 #30 0x000000304bab0f5c in KWin::Compositor::performCompositing (this=this@entry=0x1e65b30) at /usr/src/debug/kde-workspace-4.10.1/kwin/composite.cpp:610 #31 0x000000304bab1a10 in KWin::Compositor::slotCompositingOptionsInitialized (this=0x1e65b30) at /usr/src/debug/kde-workspace-4.10.1/kwin/composite.cpp:275 #32 0x000000399df8ceef in QMetaObject::activate (sender=0x1edf240, m=<optimized out>, local_signal_index=<optimized out>, argv=0x0) at kernel/qobject.cpp:3539 #33 0x000000399de6c5d7 in QFutureWatcherBase::event (this=<optimized out>, event=0x7f59a4001770) at concurrent/qfuturewatcher.cpp:344 #34 0x00000030439ca5cc in QApplicationPrivate::notify_helper (this=this@entry=0x1d38570, receiver=receiver@entry=0x1edf240, e=e@entry=0x7f59a4001770) at kernel/qapplication.cpp:4562 #35 0x00000030439cea4a in QApplication::notify (this=0x7fff5779a3f0, receiver=0x1edf240, e=0x7f59a4001770) at kernel/qapplication.cpp:4423 #36 0x00000030448473c6 in KApplication::notify (this=0x7fff5779a3f0, receiver=0x1edf240, event=0x7f59a4001770) at /usr/src/debug/kdelibs-4.10.1/kdeui/kernel/kapplication.cpp:311 #37 0x000000399df77abe in QCoreApplication::notifyInternal (this=0x7fff5779a3f0, receiver=receiver@entry=0x1edf240, event=event@entry=0x7f59a4001770) at kernel/qcoreapplication.cpp:946 #38 0x000000399df7b571 in sendEvent (event=0x7f59a4001770, receiver=0x1edf240) at kernel/qcoreapplication.h:231 #39 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x1ce1360) at kernel/qcoreapplication.cpp:1570 #40 0x0000003043a6b3bc in sendPostedEvents () at ../../src/corelib/kernel/qcoreapplication.h:236 #41 QEventDispatcherX11::processEvents (this=0x1ce2cc0, flags=...) at kernel/qeventdispatcher_x11.cpp:75 #42 0x000000399df7680f in QEventLoop::processEvents (this=this@entry=0x7fff5779a100, flags=...) at kernel/qeventloop.cpp:149 #43 0x000000399df76a98 in QEventLoop::exec (this=0x7fff5779a100, flags=...) at kernel/qeventloop.cpp:204 #44 0x000000399df7b888 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1218 #45 0x000000304ba67d6a in kdemain (argc=1, argv=0x7fff5779a538) at /usr/src/debug/kde-workspace-4.10.1/kwin/main.cpp:537 #46 0x0000003994c21a05 in __libc_start_main (main=0x400960 <main(int, char**)>, argc=1, ubp_av=0x7fff5779a538, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff5779a528) at libc-start.c:225 #47 0x0000000000400991 in _start ()

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #33 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #32)

Thanks, Knut, for bisecting in #27. Thanks, Stan, for confirming bisection in #28.

So the bad changeset is http://cgit.freedesktop.org/mesa/mesa/commit/ ?id=35840ab189595b817fa8b1a1df8cc92474a7c38d

I read that code (out of context: I'm not familiar with Xorg code). It kind of looked as if things with obvious allocation potential were followed by asserts to check that the allocation worked. So why are we observing SIGBUS rather than assertion errors? If allocation failure is possible, even assertion failure seems harsh (but at least more diagnostic).

As per comment 29, the MSAA surface is too big to be mapped by the CPU (the CPU's window into VRAM is only 256 MB). The allocation is successful, but the CPU is not able to map the buffer due to the limited window. You get a sigbus because the mapping fails and the CPU tries to access an address beyond the PCI aperture where vram is mapped. The solution is to either disable MSAA or as per comment 29, use the GPU to initialize the CMASK/HTILE buffers rather than using the CPU.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #35 from D. Hugh Redelmeier hugh@mimosa.com --- I finally am trying to set the GART size, as per Alex's comment #12.

Without setting it, Xorg0.log reports: [ 15.054] (II) RADEON(0): mem size init: gart size :1fdef000 vram size: s:20000000 visible:1f020000

The default GART size is 512MiB, You'd think that would be a good match for the 512MiB video RAM on my card. This output shows that the GART size is reduced by a somewhat odd number (13^2 * 2^12).

When I set radeon.gartsize=1024 on the kernel line, Xorg.0.log reports: [ 14.842] (II) RADEON(0): mem size init: gart size :3fdef000 vram size: s:20000000 visible:1f020000

Again, the GART size is reduced by the same amount.

Wait: according to http://dri.freedesktop.org/wiki/GART/ the GART seems to enable the video card to access the computer's memory, not the other way around. So I don't see how this is relevant: we're getting a crash in a CPU instruction that is trying to access the video card's memory.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #37 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #35)

Wait: according to http://dri.freedesktop.org/wiki/GART/ the GART seems to enable the video card to access the computer's memory, not the other way around. So I don't see how this is relevant: we're getting a crash in a CPU instruction that is trying to access the video card's memory.

GART and VRAM are separate. As I said in comment 12, I though there may have been two issues at play at first, but upon further debugging, it appears to just be the vram window.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #39 from Marek Olšák maraeo@gmail.com --- BTW today I have implemented buffer clearing using streamout. I'll send my patches to mesa-dev later today. We can use DMA later for selected chipsets. (I assume there'll be some quirks with DMA)

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #41 from Niels Ole Salscheider niels_ole@salscheider-online.de --- As I said before, the dma_fill function is based on dma_copy and I tried to keep the diff small. But you are right, this could be improved.

Have you created a patch to get these functions called in place of the currently broken code?

I did but I was missing the context that is needed to call the dma_fill function. You can try Marek's patches on the mailing list, they work well for me.

You can try to replace the call to util_blitter_clear_buffer with the dma_fill version if you are interested in it. But I don't think that you will see any noticeable difference (given the assumtion that the dma version works).

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #43 from Fredrik Höglund fredrik@kde.org --- (In reply to comment #42)

As i said in comment 30 it's also a bug of kwin, kwin should not use msaa visual for everything ...

I've pushed a patch to the stable branch in KDE that should fix this issue.

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #45 from Emil Velikov emil.l.velikov@gmail.com --- (In reply to comment #44)

What version of cogl should I look for? I can add something about this to the Fedora bug report.

commit: 93b7b4c850dd928bf21ee168a95641a8d631f713 Author: Jerome Glisse jglisse@redhat.com

glx do not use multisample visual config for front or pixmap

There is no guaranty that glXGetFBConfigs will return fbconfig ordered with non msaa config first. This patch make sure that non msaa config get choose.

Present only in the master branch. Mind you I'm not a dev, but I've sent a request[1] to pull it the 1.12, 1.14 branches. Hope they will pick it up soon

Emil

[1] http://lists.freedesktop.org/archives/cogl/2013-April/001090.html

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #47 from Fredrik Höglund fredrik@kde.org --- (In reply to comment #46)

(In reply to comment #43)

...

I've pushed a patch to the stable branch in KDE that should fix this issue.

Could you post a link to that patch?

http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=a021eacf

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #48 from Marco Trevisan (Treviño) mail@3v1n0.net --- Noticed the same issue in unity (compiz, actually) as soon as the opengl plugin is loaded.

It seems to happen mostly in multi-monitor: http://paste.ubuntu.com/5661055/

https://bugs.freedesktop.org/show_bug.cgi?id=61182

Alex Deucher agd5f@yahoo.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #51 from Nikoli nikoli@lavabit.com --- This bug is not fixed, still happens with kwin-4.10.4 and mesa-9.1.4 https://bugs.kde.org/show_bug.cgi?id=322773 https://bugs.gentoo.org/show_bug.cgi?id=476606

https://bugs.freedesktop.org/show_bug.cgi?id=61182

--- Comment #53 from Nikoli nikoli@lavabit.com --- Done, bug #67265