Display freeze when changing kwin effects settings if effects are active

[Scott Kitterman]

Binary package hint: kdebase-workspace

When changing kwin (KDE window effects) effects settings if compositing is active, the screen will freeze.

RELEASE NOTE: In a KDE Plasma Workspace, when changing desktop effects settings with effects active, the display will freeze. This can be avoided by disabling effects, making the desired settings change, and then re-enabling effects. If the display freezes, effects can be disabled using shift+alt+f12 and the display will, in most cases, unfreeze.

[Carl (carl-redhat-bugs)]

Description of problem:

Take a look at the upstream bug report =)

Version-Release number of selected component (if applicable):

F14
mesa-dri-drivers-7.9-0.6.fc14.x86_64
mesa-libGL-7.9-0.6.fc14.x86_64
xorg-x11-drv-ati-6.13.1-1.20100705git37b348059.fc14.x86_64
xorg-x11 : 1.8.99.906
kdebase-workspace-4.5.0-2.fc14.x86_64

01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870] (prog-if 00 [VGA controller])

How reproducible:

Always

Steps to Reproduce:
1. Turn the desktop effects on (using OpenGL)
2. Change the window decoration (for example), click on apply

Actual results:

The cursor still move, the audio keep playing but everything else seems to be "frozen".

Additional info:

[Thomas (thomas-redhat-bugs)]

I can reproduce that with my HD 3650 in KDE 4.5.1

mesa-dri-drivers-7.8.1-8.fc13.x86_64
mesa-libGL-7.8.1-8.fc13.x86_64
xorg-x11-drv-ati-6.13.0-1.fc13.x86_64
kdebase-workspace-4.5.1-0.1.fc13.x86_64

[Thomas (thomas-redhat-bugs)]

In a konsole running:

export LIBGL_ALWAYS_INDIRECT=1 ; kwin --replace

makes the freeze go away.
Currently the only that can be done according to upstream bug:

http://bugs.kde.org/show_bug.cgi?id=241402#c52 and following posts.

Thanks rdieter for testing it as first in IRC :)

[Scott Kitterman (kitterman)]

Confirmed by multiple reporters on IRC.

[Scott Kitterman (kitterman)]

Opening release notes task since this is unlikely to be fixed before release.

[Liviu Beraru (beraru-liviu)]

Same here on Maverick Beta. After changing some desktop settings, kde freezes (only the mouse can be moved) and I have to physically restart the computer. I don't have this problem when running Lucid. When it freezes, I have no idea how to collect any debugging information.

[Scott Kitterman (kitterman)]

Is it desktop effects settings? If so, no additional debugging is needed. Upstream is working on a fix. If not, please file a new new bug.

[John Stanley (jpsinthemix)]

Created attachment 38733
patch to Change windowExistsErrorHandler to drawableExistsErrorHandler in glxcmds.c

There currently exists a situation in KDE-4.5.X where at certain moments, a current context does not have a valid associated Window, but does have a valid pixmap drawable. If, at such a moment, a call is made to glXDestroyContext() on another no longer needed non-current context, glXDestroyContext() releases pixmap-associated resources that are in use by the current context, resulting in system hangs.

A possible patch to remedy this changes BadWindow to BadDrawable in
windowExistsErrorHandler of Mesa-7.8.3-rc1.old/src/glx/glxcmds.c (I have also attached the patch; does this make sense?):

--- Mesa-7.8.3-rc1.old/src/glx/glxcmds.c 2010-09-16 03:14:45.074000414 -0400
+++ Mesa-7.8.3-rc1.new/src/glx/glxcmds.c 2010-09-16 03:37:43.932000358 -0400
@@ -68,14 +68,14 @@

 #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)

-static Bool windowExistsFlag;
+static Bool drawableExistsFlag;
 static int
-windowExistsErrorHandler(Display * dpy, XErrorEvent * xerr)
+drawableExistsErrorHandler(Display * dpy, XErrorEvent * xerr)
 {
    (void) dpy;

- if (xerr->error_code == BadWindow) {
- windowExistsFlag = GL_FALSE;
+ if (xerr->error_code == BadDrawable) {
+ drawableExistsFlag = GL_FALSE;
    }
    return 0;
 }
@@ -98,13 +98,13 @@
    /* Set no-op error handler so Xlib doesn't bail out if the windows
     * has alreay been destroyed on the server. */
    XSync(dpy, GL_FALSE);
- oldXErrorHandler = XSetErrorHandler(windowExistsErrorHandler);
+ oldXErrorHandler = XSetErrorHandler(drawableExistsErrorHandler);

    if (__glxHashFirst(sc->drawHash, &draw, (void *) &pdraw) == 1) {
       do {
- windowExistsFlag = GL_TRUE;
+ drawableExistsFlag = GL_TRUE;
          XGetWindowAttributes(dpy, draw, &xwa); /* dummy request */
- if (!windowExistsFlag) {
+ if (!drawableExistsFlag) {
             /* Destroy the local drawable data, if the drawable no
                longer exists in the Xserver */
             (*pdraw->destroyDrawable) (pdraw);

[Rex (rex-redhat-bugs)]

kde upstream has come to the conclusion this is a mesa bug,
https://bugs.kde.org/show_bug.cgi?id=241402#c95

Filed here,
https://bugs.freedesktop.org/show_bug.cgi?id=30220

With small patch provided.

[Rex (rex-redhat-bugs)]

Here's a f13 scratch build that includes the aforementioned patch,
http://koji.fedoraproject.org/koji/taskinfo?taskID=2471720

My own initial testing (for ~20 minutes, several systemsettings modifications) has been good, no badness yet.

[Scott Kitterman (kitterman)]

This turns out to be a mesa bug. I built a test package with the mesa from the upstream mesa bug referenced in the linked KDE bug:

KDE: http://bugs.kde.org/show_bug.cgi?id=241402

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

I'll attach a debdiff in a bit.

[Scott Kitterman (kitterman)]

The author of the patch cautions that such a change my expose other problems
like memory leaks with some drivers. Personally, I'll take a memory leak over
system freezes, but I don't see any evidence of it so far.

[John Stanley (jpsinthemix)]

Created attachment 38759
Patch to fix GarbageCollectDRIDrawables for Pixmaps w/o a Window

[Thomas (thomas-redhat-bugs)]

Confirmed. The patch seems to fix it. I changed several settings and it worked as expected. No freezing.

Thanks Rex! :)

[Rex (rex-redhat-bugs)]

Second upstream patch candidate/scratch-build,
http://koji.fedoraproject.org/koji/taskinfo?taskID=2472903

[Thomas (thomas-redhat-bugs)]

Works as well as expected. Seems even better. Some glitches i had are gone.

[Rex (rex-redhat-bugs)]

And patch adapted for a f14 scratch build,
http://koji.fedoraproject.org/koji/taskinfo?taskID=2474366

[mint-fm2-dev (mint-fm2-dev)]

Please do look into this bug as it affects a wide range of hardware and a lot of users as is evidenced in the KDE bug report.

If more information is required to implement or find the proper resolution, I will try to provide what I can.

[Chris Halse Rogers (raof)]

Hm. That patch doesn't apply to a clean 7.9 tree. I think this bug is caused by the mesa workaround for bug #638808. Could you test mesa 7.9~git20100909-0ubuntu1 and check that it does not appear there?

[Scott Kitterman (kitterman)]

The patch applies to -0ubuntu2. I can adjust it to apply to whichever version you want. The problem definitely existed with -0ubuntu1 as well (and the previous 7.8.2 package).

[Chris Halse Rogers (raof)]

The code posted applies to mesa 7.8, but has been removed in 7.9. It would be useful to
a) Test if this bug still applies to mesa 7.9 from git (I've been told it applies to a snapshot from 2010/09/09, but haven't been able to reproduce it myself).

and if it still occurs, then
b) Port the patch to the 7.9 branch & master.

[John Stanley (jpsinthemix)]

(In reply to comment #3)
> The code posted applies to mesa 7.8, but has been removed in 7.9. It would be
> useful to
> a) Test if this bug still applies to mesa 7.9 from git (I've been told it
> applies to a snapshot from 2010/09/09, but haven't been able to reproduce it
> myself).
>
> and if it still occurs, then
> b) Port the patch to the 7.9 branch & master.

Thanks for looking at this. So, do I understand correctly, that the patch is ok on Mesa-7.8.x ? If this is so, then everyone now using KDE-4.5.x (and presumably Mesa-7.8.x), can use it.

I'd love also to test it out on 7.9 -- but I tried several weeks ago and ran into trouble -- I think with the intel driver (xf86-video-intel-2.12.0). I'll try again and get back to you on this.

Have you or anyone had a chance to look at BUG #30217 ?

thanks again

[Launchpad Janitor (janitor)]

This bug was fixed in the package mesa - 7.9~git20100924-0ubuntu1

---------------
mesa (7.9~git20100924-0ubuntu1) maverick; urgency=low

  * New upstream snapshot from the 7.9 release branch up to commit 3ad02793.
    - Fixes GPU hang in occlusion-query on i965 (LP: #634683)
    - Fixes hang/crash when changing desktop-effects settings in
      KDE. (LP: #633406)
  * debian/rules:
    - Update configure options for kms → drm EGL backend name change
    - Remove unused HAVE_KMS variable.
 -- Christopher James Halse Rogers <email address hidden> Thu, 23 Sep 2010 11:25:10 +1000

[Scott Kitterman (kitterman)]

Bug fixed, so no release note needed.

[Rex (rex-redhat-bugs)]

Created attachment 451295
patch proposed in upstream tracker

Patch against f13's mesa-7.8.x

[Rex (rex-redhat-bugs)]

Created attachment 451296
mesa-7.9 patch proposed upstream

[Rex (rex-redhat-bugs)]

Testing feedback for proposed patch has been excellent. I'd move it be reviewed and considered for fedora's packaging (or in the least, poke those in the know upstream to review this prior to f14 release).

To be clear, the impact here is fairly large kde-wise, even though compositing is not enabled by default, this issue makes kwin compositing largely useless for most users of free drivers, easily prone to display freezes.

[John Stanley (jpsinthemix)]

I just did a build using Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) (i915), with xorg-server-1.9.0, xf86-video-2.13.0, libdrm-2.4.22, mesa-7.9-rc2, qt-4.7.0, kde-4.5.1, and linux-2.6.35.7. This is decidedly way downhill (from xorg-server-1.8.2/Mesa-7.8.2) - desktop effects will not even activate anymore. I can force-activate them, but then video is so slow as to be entirely unusable. Perhaps related to a new error message in .xsession-errors:

i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4)

This is the only error (Xorg.0.log looks good).

Summary of some build variations (all using qt-4.7.0, kde-4.5.1., and linux-2.6.35.7):

mesa-7.8.2, libdrm-2.4.21, xorg-server-1.8.2, xf86-video-2.12.0
  ----> works (with glxcmd.c patch submitted earlier)

mesa-7.8.2, libdrm-2.4.22, xorg-server-1.8.2, xf86-video-2.13.0
   ----> works (with glxcmd.c patch submitted earlier)

mesa-7.8.2, libdrm-2.4.21, xorg-server-1.9.0, xf86-video-2.13.0
   ----> cannot start X -- cannot connect to server

mesa-7.8.2, libdrm-2.4.22, xorg-server-1.9.0, xf86-video-2.13.0
   ----> cannot start X -- cannot connect to server

mesa-7.9rc2, libdrm-2.4.22, xorg-server-1.8.2, xf86-video-2.13.0
   ----> cannot start X -- cannot connect to server

mesa-7.9rc2, libdrm-2.4.22, xorg-server-1.9.0, xf86-video-2.13.0
   ----> X runs, but no openGL available under kde
         (forcing openGL is SLOW: 5 seconds to move a window, plus various artifacts
   ----> i915_program_error: Exceeded max nr indirect texture lookups (8 out of 4);
         (src/mesa/drivers/dri/i915/i915_program.c)

[Rex (rex-redhat-bugs)]

woo, ajax gave blessing on irc to incoporate this. I'll work on it.

[Rex Dieter (rdieter)]

Re: comment #3

Testing using Fedora 14 beta,
kernel-2.6.35.4-28.fc14
libdrm-2.4.21-3.fc14
mesa-7.9-0.8.fc14
xorg-x11-server-1.9.0-9.fc14
xorg-x11-drv-intel-2.12.0-6.fc14

mesa here is a 20100922 git snapshot. I can confirm the original symptoms remain.

[Adam (adam-redhat-bugs)]

is this the thing that makes KDE really slow in a KVM? I guess not since you say it's 'not enabled by default'?

"I'd move it be reviewed and considered for fedora's packaging"

We can certainly review this as a blocker as you've nominated, but just to reinforce, an issue does not need to be a blocker for a fix to be included in F14. Right now, the bug needs no special status, you can push a fix for this in simply by submitting an update and sending it through the normal Bodhi process. Once we hit freeze, if you want to have a patch taken through a fix you still don't need to nominate the bug as a blocker if it doesn't meet the criteria; you can nominate it as nice-to-have instead. The formal NTH process is still very new and in draft stage (up till now it's all been in various people's heads), but for practical purposes, to nominate a bug as NTH, just mark it as blocking F14-accepted instead of F14blocker .

[John Stanley (jpsinthemix)]

An update with some good news regarding comment #3:

I did further testing with the following setup:

  Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (i915)
  xorg-server-1.9.0, xf86-video-2.13.0, libdrm-2.4.22, mesa-7.9-rc2, qt-4.7.0
  kde-4.5.1, linux-2.6.35.7

As I stated in comment #5, with this build, desktop (GLX) effects will not activate. There's a kde desktop effect called 'blur' which is activated on first kde-desktop boot on my system, but has never worked on my system. Up to now, I've just left it on as it doesn't appear to cause any problems. However, with this new build, 'blur' is in fact the culprit: if I first manually turn off this effect then GLX effects are activated, and the Pixmap destroy issue does not occur.

Conclusion: Problem exists in Mesa-7.8.2/3rc1, but has been fixed in Mesa-7.9rc2.

The unrelated 'blur' issue, at least for the moment, is kde's problem...

thanks for your time.

[Rex (rex-redhat-bugs)]

Ah, ajax hinted this to me in irc, but I failed to notice until now... seems the f14 branch in git got a new snapshot recently (newer than master/), and the patched code in question is very much different now. This will need to be retested (removing f14 blockers until reconfirmed).

applied the patch to f13 branch at least.

Re: comment 13 , no this almost certainly isn't the kvm slow thing (still trying to get a handle on that)

[Fedora (fedora-redhat-bugs)]

mesa-7.8.1-9.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/mesa-7.8.1-9.fc13

[Rex (rex-redhat-bugs)]

confirmed
mesa-libGL-7.9-0.8.fc14.x86_64
still has the problem. kwin freezes. :(

[Rex (rex-redhat-bugs)]

Now for some good news,

Mesa-7.9 (final) seems to have fixed the problem. Testing with quick-n-dirty scratch build that includes
ftp://ftp.freedesktop.org/pub/mesa/7.9/MesaLib-7.9.tar.bz2
No longer suffers from this bug,
http://koji.fedoraproject.org/koji/taskinfo?taskID=2513625

Marking NTH

[Orion (orion-redhat-bugs)]

FWIW - I'm able to run Rex's mesa 7.9-0.8.fc14.1 fine on my nVidia Corporation G98 [Quadro NVS 295] box with mesa-dri-drivers-experimental installed.

[Magnus (magnus-redhat-bugs)]

Sadly I cannot say the same, kwin still freezes just the same.

nVidia Corporation G96 [GeForce 9500 GT] (rev a1) + mesa-dri-drivers-experimental

[Rex (rex-redhat-bugs)]

According to (k)ubuntu, a newer mesa-7.9 snapshot fixes things for them too,
https://bugs.launchpad.net/kdebase/+bug/633406/comments/10

[Rex (rex-redhat-bugs)]

caught airlied on irc, and he said a newer mesa snapshot is in the works for f14.

[Adam (adam-redhat-bugs)]

Discussed at 2010-10-08 blocker/nth review, accepted as NTH.

[Adam (adam-redhat-bugs)]

re-assigning to Dave. Dave, just to make sure you're aware, change deadline for F14 final is Oct 18th, we need the new mesa build before then. Thanks!

(not sure why this is in 'modified' if a fixed build isn't actually available yet?)

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[James (james-redhat-bugs)]

(In reply to comment #23)
> (not sure why this is in 'modified' if a fixed build isn't actually available
> yet?)

Moving back to ASSIGNED based on previous comment

[Fedora (fedora-redhat-bugs)]

mesa-7.9-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/mesa-7.9-1.fc14

[Dave (dave-redhat-bugs)]

okay guys please test and karma as appropriate.

[Magnus (magnus-redhat-bugs)]

Ok, this one works for me

[Fedora (fedora-redhat-bugs)]

mesa-7.9-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update mesa'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/mesa-7.9-1.fc14

[Fedora (fedora-redhat-bugs)]

mesa-7.9-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.

[Fedora (fedora-redhat-bugs)]

mesa-7.8.1-9.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.

[Ajax-a (ajax-a)]

Closing per comment #7