Window Managers instability with r600 radeon and high monitor resolutions

Bug #1174495 reported by sfar on 2013-04-29
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Compiz
Critical
Marco Trevisan (Treviño)
0.9.9
Critical
Marco Trevisan (Treviño)
Mesa
Fix Released
Medium
cogl (Ubuntu)
Undecided
Unassigned
Raring
Undecided
Unassigned
Saucy
Undecided
Unassigned
compiz (Ubuntu)
Undecided
Marco Trevisan (Treviño)
Raring
Undecided
Marco Trevisan (Treviño)
Saucy
Undecided
Marco Trevisan (Treviño)
kde-workspace (Ubuntu)
Medium
Harald Sitter
Raring
Medium
Harald Sitter
Saucy
Medium
Harald Sitter
mesa (Ubuntu)
Undecided
Unassigned

Bug Description

[Impact]
KWin 4.10.2 and Compiz 0.9.9 are using MSAA visuals with 13.04's mesa.
This is unintended and leads to resource exhaustion which eventually crashes the WM.
This affects all users on the r600 with sufficiently sized displays.

[Test Case]
Run Kwin or Unity with an r600 card, if it does not crash after a while we are happy.

[Regression Potential]
None, the fix was done by an upstream KWin and Mesa developer plus it has been incorporated into Fedora for a while plus it was used elsewhere in KWin already but not in this specific code path.

[Other Info]
None.

--------------------------------------

I think the version of kwin included in 13.04 contains a known bug as described here:
https://bugs.kde.org/show_bug.cgi?id=315089
https://bugs.freedesktop.org/show_bug.cgi?id=61182

My understanding of the problem is as follows:
* The Mesa radeon r600 driver recently added support for MSAA GLX visuals
* Kwin isn't aware of MSAA properties and happens to (incorrectly) pick MSAA visuals for everything
* These visuals occupy a large amount of memory when running at high monitor resolutions
* Mesa is "only" capable of mapping 256MB of visuals into CPU address space at once
* Kwin's oversize visuals exceeds this limit, resulting in constant crashes

The two radeon systems I have both crash immediately after logging in, when running with at a resolution of 2560x1440 and desktop effects enabled. After restarting kwin, a crash can be induced by performing actions that triggers desktop effects/animations. The resulting callstack is attached.

ProblemType: BugDistroRelease: Ubuntu 13.04
Package: kde-window-manager 4:4.10.2-0ubuntu2
ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8
Uname: Linux 3.8.0-19-generic x86_64
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
Date: Mon Apr 29 19:53:57 2013
InstallationDate: Installed on 2013-04-27 (2 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MarkForUpload: TrueSourcePackage: kde-workspace
UpgradeStatus: No upgrade log present (probably fresh install)

--------------------------------------

Compiz (unity) is affected by the same issue as shown in this stacktrace:

http://paste.ubuntu.com/5661055/

Related branches

Download full text (5.1 KiB)

Kwin crashes with current mesa and kernel 3.8. It does not crash with 3.7 kernel. With mesa 9.0.2 and kernel 3.8 kwin also works fine

#5 0x0000003647c892ab in __memset_sse2 () from /lib64/libc.so.6
#6 0x00007f5a8cbf6cf3 in r600_texture_create_object (screen=0x980ca0, base=0x7fff208b4770, pitch_in_bytes_override=0, buf=0x0, surface=0x7fff208b3a80) at r600_texture.c:509
#7 0x00007f5a8cbf7339 in r600_texture_create (screen=0x980ca0, templ=0x7fff208b4770) at r600_texture.c:601
#8 0x00007f5a8cbdbae5 in r600_resource_create (screen=0x980ca0, templ=0x7fff208b4770) at r600_resource.c:37
#9 0x00007f5a8cc1b4d2 in dri2_drawable_process_buffers (drawable=0xc2b130, buffers=0x764460, buffer_count=1, atts=0x7fff208b48b0, att_count=1) at dri2.c:254
#10 0x00007f5a8cc1b9b3 in dri2_allocate_textures (drawable=0xc2b130, statts=0x7fff208b48b0, statts_count=1) at dri2.c:404
#11 0x00007f5a8cc19f0f in dri_st_framebuffer_validate (stfbi=0xc2b130, statts=0x7fff208b48b0, count=1, out=0x0) at dri_drawable.c:81
#12 0x00007f5a8cc1a30e in dri_drawable_validate_att (drawable=0xc2b130, statt=ST_ATTACHMENT_FRONT_LEFT) at dri_drawable.c:206
#13 0x00007f5a8cc1a35c in dri_set_tex_buffer2 (pDRICtx=0x8fef20, target=3553, format=8409, dPriv=0xbee5e0) at dri_drawable.c:220
#14 0x00007f5a9b82f590 in dri2_bind_tex_image (dpy=0x7d15f0, drawable=29360171, buffer=8414, attrib_list=0x0) at dri2_glx.c:1002
#15 0x00007f5a9b7f30f5 in __glXBindTexImageEXT (dpy=0x7d15f0, drawable=29360171, buffer=8414, attrib_list=0x0) at glxcmds.c:2370
#16 0x00007f5a9d1773c3 in KWin::GlxTexture::loadTexture(unsigned long const&, QSize const&, int) () from /usr/lib64/libkdeinit4_kwin.so
#17 0x00007f5a9d16f175 in KWin::SceneOpenGL::Window::bindTexture() () from /usr/lib64/libkdeinit4_kwin.so
#18 0x00007f5a9d175a8e in KWin::SceneOpenGL::Window::performPaint(int, QRegion, KWin::WindowPaintData) () from /usr/lib64/libkdeinit4_kwin.so
#19 0x00007f5a9d16e32f in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib64/libkdeinit4_kwin.so
#20 0x00007f5a9d16e4cd in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib64/libkdeinit4_kwin.so
#21 0x00007f5a9d1822b5 in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib64/libkdeinit4_kwin.so
#22 0x00007f5a9d16178a in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib64/libkdeinit4_kwin.so
#23 0x00007f5a9d182557 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib64/libkdeinit4_kwin.so
#24 0x00007f5a9d16434d in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) () from /usr/lib64/libkdeinit4_kwin.so
#25 0x00007f5a9d16367f in KWin::Scene::paintSimpleScreen(int, QRegion) () from /usr/lib64/libkdeinit4_kwin.so
#26 0x00007f5a9d1616ce in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib64/libkdeinit4_kwin.so
#27 0x00007f5a9d182720 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintD...

Read more...

This happens only when kwin starts for the first time. There are no crashes at next runs.

Same crash with the same backtrace using mesa 9.1 and kernel 3.8

With "glamor" as acceleration method, these crashes are much more rare

I can confirm a very similar crash:

#5 0x00007fb122be859b in __memset_sse2 () from /usr/lib/libc.so.6
#6 0x00007fb072bd0a5f in r600_texture_create_object () from /usr/lib/xorg/modules/dri/r600_dri.so
#7 0x00007fb072bd0d37 in r600_texture_create () from /usr/lib/xorg/modules/dri/r600_dri.so
#8 0x00007fb072be3145 in dri2_allocate_textures () from /usr/lib/xorg/modules/dri/r600_dri.so
#9 0x00007fb072be1c65 in dri_st_framebuffer_validate () from /usr/lib/xorg/modules/dri/r600_dri.so
#10 0x00007fb072be1e9e in dri_set_tex_buffer2 () from /usr/lib/xorg/modules/dri/r600_dri.so
#11 0x00007fb122fd94b3 in ?? () from /usr/lib/libkdeinit4_kwin.so

(I don't have debug symbols for kwin, and mesa was compiled in release mode).

Mesa 9.2-devel (git-4154ac0)
Kernel 3.8.0.
KDE 4.10.

I get the crash when first logging in, but I also get it every time I unlock the screen after locking it from the 'K-menu'.

The crash only occurs if compositing is on.

I forgot to add:

My card is a Radeon HD 5670

The same crash happens time to time when maximizing application windows

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.

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.

This is on an x86-64 system with Radeon HD 4770.

(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?

(In reply to comment #9)
> (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?

I don't have a reliable trigger for the crash yet. If I can find one, I'll give it a try.

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.

I think these are actually several bugs at play here.

1. CPU only has a 256 MB window into vram. If the window is full due to fragmentation or other mapped buffers, we fail. Does disabling hyperz help? set env var R600_HYPERZ=0 (mesa 9.1 or older), or R600_DEBUG=nohyperz (mesa git).

2. running out of GPU accessible memory when migrating buffers. Does setting radeon.gartsize=1024 on the kernel command line in grub help?

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).

(In reply to comment #12)
> I think these are actually several bugs at play here.
>
> 1. CPU only has a 256 MB window into vram. If the window is full due to
> fragmentation or other mapped buffers, we fail. Does disabling hyperz help?
> set env var R600_HYPERZ=0 (mesa 9.1 or older), or R600_DEBUG=nohyperz (mesa
> git).
>
> 2. running out of GPU accessible memory when migrating buffers. Does
> setting radeon.gartsize=1024 on the kernel command line in grub help?

Just tried both, but nothing changed...

(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.

No gnome-shell crashes since I've upgraded to Mesa 9.1.1. Will post an update in a few days whether it remains stable or I was just lucky today.

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 (

(Sorry for the previous uncompleted comment. I will continue.)

I'm hitting it in Gnome_shell (https://bugzilla.redhat.com/show_bug.cgi?id=924076).

I'm hitting it in Cinnamon (https://bugzilla.redhat.com/show_bug.cgi?id=926036)

I'm hitting it in KWin (https://bugs.kde.org/show_bug.cgi?id=315089)

In each case, I get a SIGBUS in __memset_sse2, called from r600 code. I'm not used to getting SIGBUSes since I migrated from the PDP-11 :-).

This makes me think that it is a radeon driver bug.

One KDE developer pointed in another direction. Since it is reported as an intel driver bug, I don't think that it is right, but it might be relevant: https://bugs.freedesktop.org/show_bug.cgi?id=58834

I think that I still have crash dumps for each of these. If something from them would be useful, ask soon before I recover the space. But I think that I can regenerate one all too quickly.

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?

(In reply to comment #16)
> No gnome-shell crashes since I've upgraded to Mesa 9.1.1. Will post an
> update in a few days whether it remains stable or I was just lucky today.

Observed the same gnome-shell crash problem with Mesa 9.1.1 with kernel 3.8.4-202 also. The way how I reproduce this is to have dual monitors. The left one with resolution 1680x1050 (rotated counterclockwise) and the right with 1920x1200. With this setup, gnome-shell will always crash at initial login. If I don't rotate the left monitor, gnome-shell will not crash.

Download full text (6.3 KiB)

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::SceneO...

Read more...

Download full text (3.8 KiB)

I can also confirm this bug on Fedora 18 X86_64, radeon driver, HD5870 card.
I cannot log into the system with two external monitors attached, but with only one external monitor it works fine. This seems to have started to happen after upgrade to mesa-dri-drivers 9.1-1 or 9.1-3 (I did not restart between those updates). Here is my backtrace:
b7b62d4d01e98c8b31d95895cbede393b8b0c6e8 0x8954b __memset_sse2 /lib64/libc.so.6 45eccba94f5fef95c8933974ac014d83e50a9ebb
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x349ff2 r600_texture_create_object /usr/lib64/dri/r600_dri.so 4f51004f888b1ba8194719f476c2fd4ff4aad900
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x34a2c7 r600_texture_create /usr/lib64/dri/r600_dri.so 5baaed899c5ecf15a1568310eff18dc385cdf50d
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35ca25 dri2_allocate_textures /usr/lib64/dri/r600_dri.so 0a2fa38b05320f36fa5b90de563948aac101910e
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35b595 dri_st_framebuffer_validate /usr/lib64/dri/r600_dri.so 45eccba94f5fef95c8933974ac014d83e50a9ebb
c9e82f1ca30be88ed6ef697aa581a1c940858291 0x35b7ce dri_set_tex_buffer2 /usr/lib64/dri/r600_dri.so 55f8abe768545f45025c61cca676f0352439722d
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x68702 _cogl_winsys_texture_pixmap_x11_update /lib64/libcogl.so.11 ac79bd8478de58b10ea1b2bbc9d920bfbe437214
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x66104 _cogl_texture_pixmap_x11_update /lib64/libcogl.so.11 96f709cfd3fe851395649feeda7d4dd459e3ca60
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x666ad _cogl_texture_pixmap_x11_get_texture /lib64/libcogl.so.11 6179db327fe5f11fb226532cabb471745b820c8f
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x66709 _cogl_texture_pixmap_x11_get_type /lib64/libcogl.so.11 ad318b56f9bf3c97e02782cfada93e8f37221c59
67f4899c1db4d10dd1558ccbb7b8fad4e81e3379 0x437d9 cogl_pipeline_set_layer_texture /lib64/libcogl.so.11 ba1ae932f4a148b027fd73337e04d05fbae9862e
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x33eb2 set_texture_on_actor /lib64/libmutter.so.0 47169c9a5b07212ae0061e199a81ca87080a2e4c
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x34008 set_texture /lib64/libmutter.so.0 6647294c524f089a0c77389826b0a954c997c085
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x3491f meta_background_actor_update /lib64/libmutter.so.0 184cb323b2f3eaf40fc3b375371bdf1393e6882a
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x3352a meta_compositor_process_event /lib64/libmutter.so.0 5c8e84a4b7a1c62daf4be566f862cf325d9b1926
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x45367 event_callback /lib64/libmutter.so.0 11cf28c10df323150560c808d8bf75e7ed72e0c8
c043a38bda0d5dc29bb15a1e211273a4ec3dea5d 0x8f476 filter_func /lib64/libmutter.so.0 7bfd96ce0e83046b4b4da64b6d99cf1d3ce823d6
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4a901 gdk_event_apply_filters /lib64/libgdk-3.so.0 a28856cf0bdff41c2ad87be20d4186aeea868a26
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4aad7 _gdk_x11_display_queue_events /lib64/libgdk-3.so.0 50da1079f5dfea096a6ddfd4caca8af2b76726e4
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x20511 gdk_display_get_event /lib64/libgdk-3.so.0 457cc16f8850789e7b3830330439fcf89b9a418b
1c54a46d2f8de1beadccfa39550b5eef67ab6bc0 0x4a812 gdk_event_source_dispatch /lib64/libgdk-3.so.0 d2...

Read more...

I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged by Fedora) fixes the problem.

(In reply to comment #23)
> I can confirm now that downgrading mesa-dri-drivers to 9.0.1-1 (as packaged
> by Fedora) fixes the problem.

Can you bisect mesa?

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?

*** Bug 61822 has been marked as a duplicate of this bug. ***

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.

Download full text (8.5 KiB)

Here happens similar thing. KWin with desktop effects enabled crashes on login to KDE and after resume from suspend with 100% reproductibility.

My config Fedora 18.
 - kernel-PAE-3.8.5-201.fc18.i686
 - libdrm-2.4.42-1.fc18.i686
 - xorg-x11-server-Xorg-1.13.3-2.fc18.i686
 - mesa-dri-drivers-9.1-3.fc18.i686
 - kde 4.10.2-1

Backtrace:
Application: KWin (kwin), signal: Bus error
Using host libthread_db library "/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0xb769c780 (LWP 18403))]

Thread 2 (Thread 0xb1644b40 (LWP 18417)):
#0 0xb7784424 in __kernel_vsyscall ()
#1 0x4145e18c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S:171
#2 0xb2d5c20c in pipe_semaphore_wait (sema=0xb4190b50) at ../../../../../src/gallium/auxiliary/os/os_thread.h:433
#3 radeon_drm_cs_emit_ioctl (param=0xb4170008) at radeon_drm_cs.c:416
#4 0x4145aaff in start_thread (arg=0xb1644b40) at pthread_create.c:308
#5 0x4138a0be in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:132

Thread 1 (Thread 0xb769c780 (LWP 18403)):
[KCrash Handler]
#7 __memset_sse2 () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:331
#8 0xb2d2f186 in r600_texture_create_object (screen=screen@entry=0x9342718, base=base@entry=0xbfc4b1e4, pitch_in_bytes_override=pitch_in_bytes_override@entry=0, buf=buf@entry=0x0, alloc_bo=alloc_bo@entry=1 '\001', surface=surface@entry=0xbfc4a4d8) at r600_texture.c:460
#9 0xb2d2f49c in r600_texture_create (screen=screen@entry=0x9342718, templ=templ@entry=0xbfc4b1e4) at r600_texture.c:550
#10 0xb2d28564 in r600_resource_create (screen=0x9342718, templ=0xbfc4b1e4) at r600_resource.c:37
#11 0xb2d5650f in dri2_drawable_process_buffers (att_count=1, atts=0xbfc4b2a4, buffer_count=1, buffers=0x94cccbc, drawable=<optimized out>) at dri2.c:254
#12 dri2_allocate_textures (drawable=0x94dad88, statts=0xbfc4b2a4, statts_count=1) at dri2.c:404
#13 0xb2d5788c in dri_st_framebuffer_validate (stfbi=0x94dad88, statts=0xbfc4b2a4, count=1, out=0x0) at dri_drawable.c:81
#14 0xb2d57ab7 in dri_drawable_validate_att (statt=ST_ATTACHMENT_FRONT_LEFT, drawable=0x94dad88) at dri_drawable.c:206
#15 dri_set_tex_buffer2 (pDRICtx=0x9310270, target=3553, format=8409, dPriv=0x948c7a0) at dri_drawable.c:220
#16 0xb771b770 in dri2_bind_tex_image (dpy=0x91897e8, drawable=29360181, buffer=8414, attrib_list=0x0) at dri2_glx.c:1004
#17 0xb76efa93 in __glXBindTexImageEXT (dpy=0x91897e8, drawable=drawable@entry=29360181, buffer=buffer@entry=8414, attrib_list=attrib_list@entry=0x0) at glxcmds.c:2370
#18 0x447d5a8c in loadTexture (depth=24, size=..., pix=@0xbfc4b40c: 29360179, this=0x9494f08) at /usr/src/debug/kde-workspace-4.10.2/kwin/glxbackend.cpp:716
#19 KWin::GlxTexture::loadTexture (this=0x9494f08, pix=@0xbfc4b40c: 29360179, size=..., depth=24) at /usr/src/debug/kde-workspace-4.10.2/kwin/glxbackend.cpp:658
#20 0x447ca65a in KWin::SceneOpenGL::Texture::load (this=0x92df3a8, pix=@0xbfc4b40c: 29360179, size=..., depth=24, region=...) at /usr/src/debug/kde-workspace-4.10.2/kwin/scene_opengl.cpp:764
#21 0x447ccaf7 in KWin::SceneOpenGL::Window::bindTexture (this=0x94ccbd0) at /usr/src/debug/kde-workspace-4.10.2/kwin/scene_opengl.cpp:822
#22 0x4...

Read more...

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.

Well this is also a kwin bug, kwin should not pick MSAA visual. I fixed cogl so that it does not pick msaa visual for gnome-shell.

Download full text (6.2 KiB)

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, ...

Read more...

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).

(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.

Thanks, Alex, for the clear restatement.

Naively, I think of two C/UNIX conventions. For allocations that can either succeed or fail, typically the result is a pointer which is NULL for failure -- eg. malloc(3)). For allocations that can partially succeed, the result is the amount successfully processed (think write(2) which returns the length actually transferred).

It seems to me that for allocating address space in the VRAM window (aperture?), success can partial, and anything that deals with that window needs to be aware that accessing some object may require piecewise operations, punctuated by adjustment of the mapping.

In other words, this case doesn't sound pathological; it should be handled as a normal case.

I'm not saying that comment #29 is wrong. I'm saying that the existing code ought to have been written to handle this case. Clearly one solution is to replace the code as suggested. But fixing the code ought to be feasible too. Are there other lurking bugs where code assumes addressability?

I reiterate: I'm not knowledgeable about modern video architectures or about X server architectures.

Footnote: Why do I think that VRAM windows cannot always map the whole VRAM? Because video cards now routinely have gigabytes of VRAM and 32-bit address spaces for x86 machines cannot spare enough to allocate for that much VRAM (ignoring PAE).

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.

(In reply to comment #34)
> I'm not saying that comment #29 is wrong. I'm saying that the existing code
> ought to have been written to handle this case. Clearly one solution is to
> replace the code as suggested. But fixing the code ought to be feasible
> too. Are there other lurking bugs where code assumes addressability?
>

It's a bug that needs to be fixed.

(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.

Created attachment 78307
dma_fill function

I considered to implement Marek's proposal by adding a dma_fill function that works analogously to dma_copy.
I need the context to call this function, though, and I do not know how to get it in r600_texture_create_object (nor if I should be able to get it at all).

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)

Thanks, Neils, for the patch in comment #38.

Warning: the following comments are made with no understanding of X code.

"writting" should be "writing"

What is 0x000fffff? I would find the code clearer if this constant were given a name (RADEON_MAX_DMA?).

Why code
  nfill = (size / 0x000fffff) + !!(size % 0x000fffff);
instead of the generally more efficient
  nfill = (size+ 0x000fffff - 1) / 0x000fffff;
My guess: to avoid overflow. But if that is the case, then nfill should be uint64_t (like size), not just unsigned (which might be only 32 bits). Any case where the second statement might have an overflow problem would also be a problem with nfill being only unsigned 32.

If you know size is not 0, this is even better:
  nfill = ((size - 1) / 0x000fffff) + 1;
If size can be 0, it is probably worth an early-out test to avoid bothering the GPU anyway:
  if (size == 0) return 0;

I find code is easier to read if the scope of a variable is minimized. So I'd make the assignment to fsize also its declaration.

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

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).

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

(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.

Jerome Glisse in comment #30:
"Well this is also a kwin bug, kwin should not pick MSAA visual. I fixed cogl so that it does not pick msaa visual for gnome-shell."

Thanks!

I am (even today) experiencing gnome-shell crashes like this on an up-to-date fedora 18 (cogl-1.12.2-1.fc18.x86_64). See my comment #18. Also in Cinnamon (untested since that report).

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

(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 <email address hidden>

    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

(In reply to comment #43)
> (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.

Could you post a link to that patch?
Thank you.

(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

sfar (sfar) wrote :
sfar (sfar) wrote :
sfar (sfar) on 2013-04-29
description: updated
Changed in kde-workspace (Ubuntu):
importance: Undecided → Medium
Harald Sitter (apachelogger) wrote :

<mgraesslin> today is the .3 tagging
<mgraesslin> so you could just wait for the packages
<apachelogger> mgraesslin: how much impact does that issue have?
<mgraesslin> it's currently one of the two most often reported crashes
<apachelogger> ... it will still take a month or so for .3 to land in regular updates
<apachelogger> ok, better manually SRU into .2 then

Changed in kde-workspace (Ubuntu):
status: New → Fix Committed
Changed in kde-workspace (Ubuntu Saucy):
status: Fix Committed → Triaged
Changed in kde-workspace (Ubuntu Raring):
status: New → Triaged
importance: Undecided → Medium
description: updated
Changed in kde-workspace (Ubuntu Raring):
status: Triaged → In Progress
Changed in kde-workspace (Ubuntu Saucy):
status: Triaged → In Progress
Changed in kde-workspace (Ubuntu Raring):
assignee: nobody → Harald Sitter (apachelogger)
Changed in kde-workspace (Ubuntu Saucy):
assignee: nobody → Harald Sitter (apachelogger)

Hello sfar, or anyone else affected,

Accepted into raring-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in kde-workspace (Ubuntu Raring):
status: In Progress → Fix Committed
tags: added: verification-needed

The proposed update seems to fix the problem for me. I've not seen the crash after 10 reboot and login attempts, whereas previously kwin crashed every time.

kde-window-manager 4:4.10.2-0ubuntu2.1 amd64
kde-workspace 4:4.10.2-0ubuntu2.1

tags: added: verification-done
removed: verification-needed
Changed in kde-workspace (Ubuntu Saucy):
status: In Progress → Confirmed
status: Confirmed → Fix Committed

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/

summary: - kwin instability with r600 radeon and high monitor resolutions
+ Window Managers instability with r600 radeon and high monitor
+ resolutions
affects: unity → compiz
Changed in compiz:
status: New → Triaged
importance: Undecided → Critical
milestone: none → 0.9.10.0
Changed in cogl:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in compiz (Ubuntu Raring):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: New → In Progress
Changed in compiz (Ubuntu Saucy):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: New → In Progress
Changed in compiz:
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: Triaged → In Progress
no longer affects: cogl
no longer affects: mesa (Ubuntu)
no longer affects: mesa (Ubuntu Raring)
no longer affects: mesa (Ubuntu Saucy)
Changed in mesa (Ubuntu):
status: New → Confirmed
Changed in cogl (Ubuntu Raring):
status: New → Confirmed

Should be fixed in mesa master and 9.1 branch with the following commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b69207642079fe8ba33c594750415e8d9c66a06f

description: updated

(In reply to comment #48)
> 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/

FYI, Compiz fix is in https://code.launchpad.net/~3v1n0/compiz/msaa-configs-ignore/+merge/163550 and tracked by bug https://bugs.launchpad.net/compiz/+bug/1174495

PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:compiz/0.9.9 at revision None, scheduled for release in compiz, milestone 0.9.9.2

Changed in compiz:
status: In Progress → Fix Committed
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:compiz at revision None, scheduled for release in compiz, milestone 0.9.10.0

Changed in compiz (Ubuntu Saucy):
status: In Progress → Fix Committed
Changed in compiz (Ubuntu Raring):
status: In Progress → Fix Committed

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package kde-workspace - 4:4.10.2-0ubuntu2.1

---------------
kde-workspace (4:4.10.2-0ubuntu2.1) raring; urgency=low

  * Add 0001-kwin-glx-Avoid-MSAA-configs-in-initDrawableConfigs.patch
    from upstream avoiding MSAA configs to resolve a crash on ATI R600
    with raring Mesa (LP: #1174495)
 -- Harald Sitter <email address hidden> Sat, 04 May 2013 10:48:05 +0100

Changed in kde-workspace (Ubuntu Raring):
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cogl (Ubuntu):
status: New → Confirmed
Changed in mesa:
importance: Unknown → Medium
status: Unknown → Fix Released
bugbot (bugbot) on 2013-05-16
tags: added: kubuntu
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package kde-workspace - 4:4.10.3-0ubuntu1

---------------
kde-workspace (4:4.10.3-0ubuntu1) saucy; urgency=low

  * New upstream release
  * Merge with Debian, remaining changes:
    - Add kdm.{links, upstart}
    - Make kdm work with upstart in kdm.prerm, kdm.postrm, kdm.postinst
    - Add kde-window-manager-gles.install and libkwineffects1abi2-gles.install
    - Move non-default kdm and ksplash themes to the new package
      kde-workspace-data-extras.
    - kdm.logrotate: rotate 7 -> rotate 2 to help stop excess disk usage
    - New binary package kde-workspace-randr to separate out randr tools,
      not installed by default as we use kscreen now
    - debian/control:
      - Build against libbost1.53-dev instead of libboost-dev
      - Keep bumped our replaces/breaks
      - kde-workspace-bin suggests plasma-scriptengines instead of
        recommend
      - kdebase-workspace-data depends on oxygen-cursor-theme instead of
        oxygencursors
      - Keep kdebase-workspace-wallpapers
      - plasma-widgets-workspace depends on akonadi-server and kdepim-runtime
      - plasma-scriptengines not depends on plasma-scriptengine-googlegadgets
      - Don't build plasma-scriptengine-googlegadgets
      - add build-dep on libgles2-mesa-dev
      - In kde-workspace recommend lightdm-kde-greeter as well as kdm
      - kde-workspace-bin optionally depends on plasma-active
      - kdm replaces/breaks old kde-workspace-data
      - Add kinfocenter Breaks/Replaces kde-workspace-data <<
        4:4.9.80-0ubuntu5~ and kde-workspace-bin << 4:4.9.80-0ubuntu5~
    - debian/patches:
      - Use kdmrc_defaults_kubuntu.diff instead of kdmrc_defaults.diff
      - Don't add be_better_at_honouring_user_kdm_theming
      - Don't add use_dejavu_as_default_font
      - Don't add fix_target_link_libraries
      - Keep our patches
  * kde-workspace-bin replaces/breaks ktouchpadenabler
 -- Jonathan Riddell <email address hidden> Wed, 08 May 2013 16:08:53 +0000

Changed in kde-workspace (Ubuntu Saucy):
status: Fix Committed → Fix Released
Sylvain Falardeau (sylvainf) wrote :

I am not sure if my problem is related because I don't crash with compiz/unity but the ALT-TAB and virtual desktop switching is buggy. The ALT-TAB content appear slowly or the desktop switcher does not disapear and I cannot click any application. Sometimes it hang for 5-8 seconds. Somtimes the ALT-TAB switcher is semi transparent but wait 5 seconds before disapearing completely.

I lowered from 1920x1200 to 1552x864 and the problem goes away (at least with a couple hours test). 1600x1200 have the same problem as 1920x1200.

Sylvain Falardeau (sylvainf) wrote :

I removed my Radeon card from my desktop and used the integrated Intel instead. I was able to use it flawlessly in 1920x1200 all the afternoon.

So even if it does not crash on me, the r600 driver does hang and make it difficult to use with Compiz+Unity.

I will try my Radeon again when the update to Compiz will be available.

FYI you can just update the compiz-plugins-default package from http://is.gd/fsl3P0 to get this fixed for your radeon card.

Sylvain Falardeau (sylvainf) wrote :

I have installed the daily packages for Raring (version 1:0.9.9~daily13.06.11~13.04) and put back my Radeon in my desktop.

It is really more stable than the default raring version. No freezing when I change virtual desktops. But I still have ALT-TAB freezes from time to time, for 2-6 seconds, then it resumes normally. Sometimes it is the fading in/out of the icons with ALT-TAB that is longer than usual.

But this problem with ALT-TAB happens also with my other machine, a Dell portable with an integrated Intel card.

At least it is workable now.

Hello sfar, or anyone else affected,

Accepted compiz into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/compiz/1:0.9.9~daily13.05.31~13.04-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: removed: verification-done
tags: added: verification-needed
Adam Conrad (adconrad) wrote :

Hello sfar, or anyone else affected,

Accepted compiz into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/compiz/1:0.9.9~daily13.06.19~13.04-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Sylvain Falardeau (sylvainf) wrote :

I installed the version 1:0.9.9~daily13.06.19-13.04-0ubuntu1 from raring-proposed and rebooted.

It seems to work like the prior daily version I installed (see #68). The virtual desktops seems to work correctly. The ALT-TAB still freezes from time to time.

Alt-Tab issue is not related to this issue, so thanks for your verification.

tags: added: verification-done
removed: verification-needed
Sylvain Falardeau (sylvainf) wrote :

I am not sure about the ALT-TAB if it is related or not. The problems I had with the old version was a combination of freezes when changing workspaces AND doing ALT-TAB. Now the workspace switching works fine but the ALT-TAB is still buggy. The showing and disappearing of the applications logos when ALT-TAB switching is buggy (freezes).

I removed my Radeon card again and rebooted with my Intel integrated card. The ALT-TAB works fine. This is why I think it is related to the Radeon bug (but it may be another one).

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.9.9~daily13.06.19~13.04-0ubuntu1

---------------
compiz (1:0.9.9~daily13.06.19~13.04-0ubuntu1) raring; urgency=low

  [ Chris Townsend ]
  * Fixed issue where minimizing an unredirect full screen window would
    repaint the full screen window after minimizing it even though it
    isn't really there. This is a backport of lp:compiz revno. 3686.
    (LP: #1053895)

  [ Marco Trevisan (Treviño) ]
  * OpenGL Screen: Ignore the MSAA configs during initialization This
    fixes a crash with new MESA drivers and high monitor resolutions
    caused by the fact that we're accidentally using some MSAA configs
    with some drivers in Mesa 9.0. Taking in account the values of
    GLX_SAMPLES and GLX_SAMPLE_BUFFERS fixes the issue. See mesa bug
    https://bugs.freedesktop.org/show_bug.cgi?id=61182. (LP: #1174495)

  [ Hu Kang ]
  * Use XIDefineCursor rather than XDefineCursor. compiz should show a
    busy cursor during the application startup stage. the corresponding
    code is in scr/screen.cpp:
    cps::StartupSequenceImpl::updateStateFeedback () the patch changes
    all XDefineCursor to XIDefineCursor (see XInput2 extension) (LP:
    #1179155). (LP: #1179155)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 3657 (bootstrap)
  * Automatic snapshot from revision 3658

compiz (1:0.9.9~daily13.05.08~13.04-0ubuntu1) raring; urgency=low

  * Automatic snapshot from revision 3652

compiz (1:0.9.9~daily13.05.01.1ubuntu.unity.next-0ubuntu1) raring; urgency=low

  * Automatic snapshot from revision 3651 (ubuntu-unity/next)
 -- Ubuntu daily release <email address hidden> Wed, 19 Jun 2013 04:02:36 +0000

Changed in compiz (Ubuntu Raring):
status: Fix Committed → Fix Released
Stephen M. Webb (bregma) on 2013-07-23
Changed in compiz:
status: Fix Committed → Fix Released

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

(In reply to comment #51)
> 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

I think you are hitting a different issue. Please open a new bug.

Launchpad Janitor (janitor) wrote :
Download full text (70.8 KiB)

This bug was fixed in the package compiz - 1:0.9.10+13.10.20130822-0ubuntu1

---------------
compiz (1:0.9.10+13.10.20130822-0ubuntu1) saucy; urgency=low

  [ Sam Spilsbury ]
  * Bump version to 0.9.10

  [ Łukasz 'sil2100' Zemczak ]
  * Remove debian/patches/unity_support_test.patch:
    - Running the support test from compiz has bad side effects, from now
      on we run it from Xsession.d
  * Automatic snapshot from revision 3644

  [ Iven Hsu ]
  * Opacify: Only dim the windows above the active window.(LP:
    #1189374). (LP: #1189374)
  * KWD: Fix compile errors with KDE 4.11. The KWin developers made
    kdecorationbridge.h private. See:
    http://lists.freedesktop.org/archives/compiz/2013-March/003479.html
    (LP: #1193792). (LP: #1193792)

  [ Nikolay Martynov ]
  * When static switcher is enabled and has an option to show
    application icon turned on the icons are expected to be ~1/3 of a
    thumbnail (48px). Instead they are displayed in 512px size and
    completely cover everything. This change addresses this issue. See
    LP #1173914. (LP: #1173914, #1186426)

  [ BryanFRitt ]
  * Fixed the non-working Annotate 'Clear' Button. Moved this option's
    CCSM position upwards to keep the button shortcuts together. (LP:
    #1202907). (LP: #1202907)

  [ Mehrdad Afshari ]
  * Added "move window to previous monitor" feature to compiz Put
    plugin. (LP: #1178581)

  [ Hu Kang ]
  * gtk-window-decorator: destroy action menu when any of the (close,
    min, max) buttons on the title bar is pressed. (LP: #1101648)
  * Remove redundant src/logmessage/include/core/logmessage.h (LP:
    #1067246). (LP: #1067246)

  [ Steve Langasek ]
  * Fix for bug #763148 (with added test cases): when the desktop is
    resized, windows should stay on their original workspace. (LP:
    #763148)

  [ Brandon Schaefer ]
  * Unrevert 3728, fix failing tests. Change the behaviour of
    undecorating windows. Previously when a window was undecorated, we
    would shift it back to an appropriate position according to its
    gravity member. That behaviour was problematic because in the
    StaticGravity case the window has to just stay in the same place.
    But then if you had a window with StaticGravity which then did get a
    decoration and later removed it, it would be placed as though it was
    decorated and appear to be in the wrong place. The correct behaviour
    is to place all windows as though they have decorations, and then
    when decorations are removed, to move the window back to the corner
    as indicated in its gravity and then expand its size to cover the
    obscured regions no longer hidden because the decorations went away.
    (LP: #1165343).   1. Completely remove decorOffsetMove and other
    related code from      decor.cpp. Put the logic to handle the
    window->input () - window->border ()      placement offset inside of
    setWindowFrameExtents instead. Now the window      will always be
    offset from its original non-decorated position to the new
         decorated position, rather than having to guess between
    decoration sizes.   2. Make saveGeometry and restoreGeometry work
    relative to window->border ()      a...

Changed in compiz (Ubuntu Saucy):
status: Fix Committed → Fix Released
Stephen M. Webb (bregma) wrote :

Closing 0.9.9 task (0.9.9 series is obsolete)

Rolf Leggewie (r0lf) wrote :

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".

Changed in cogl (Ubuntu Raring):
status: Confirmed → Won't Fix
Rolf Leggewie (r0lf) wrote :

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

Changed in cogl (Ubuntu Saucy):
status: Confirmed → Won't Fix
madbiologist (me-again) wrote :

The Mesa fix is in mesa 9.1 and later. Ubuntu 14.04 Trusty Tahr is based on mesa 10.1.

Changed in mesa (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.