Bug 77207

Try downgrading to mesa-9 or mesa-10.0.

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

I was able to reproduce this today - a sensible looking batch, but the first bunch of DWords are smashed to 0xFFFFFFFF.  Also on Haswell.  Not sure what's going on.

Mario, what version of Mesa are you using?

Il 10/04/2014 01:17, bugzilla-daemon@freedesktop.org ha avuto l'onore e
l'ardire di scrivere:
> *Comment # 3 <https://bugs.freedesktop.org/show_bug.cgi?id=77207#c3> on
> bug 77207 <https://bugs.freedesktop.org/show_bug.cgi?id=77207> from
> Kenneth Graunke <mailto:kenneth@whitecape.org> *
> 
> I was able to reproduce this today - a sensible looking batch, but the first
> bunch of DWords are smashed to 0xFFFFFFFF.  Also on Haswell.  Not sure what's
> going on.
> 
> Mario, what version of Mesa are you using?
> 

Hi,
this is mesa version on my box (updated today):

> ii  libegl1-mesa:amd64                    10.1.0-5
> ii  libegl1-mesa-drivers:amd64            10.1.0-5
> ii  libgl1-mesa-dri:amd64                 10.1.0-5
> ii  libgl1-mesa-glx:amd64                 10.1.0-5
> ii  libglapi-mesa:amd64                   10.1.0-5
> ii  libgles2-mesa:amd64                   10.1.0-5
> ii  libglu1-mesa:amd64                    9.0.0-2
> ii  libopenvg1-mesa:amd64                 10.1.0-5
> ii  libwayland-egl1-mesa:amd64            10.1.0-5 

Today I upgraded my system and goes better.

I'm still looking for new deatils.

Reguards,
Mario

Created attachment 97229 [details]
dump in /sys/class/drm/card0/error (20140411)

Our current theory is that Mesa is allocating insufficient memory for the MCS buffers, and the GPU is running off the end of those and trampling whatever happens to come after it in memory.  In this case, that's the batchbuffer.  In MCS speak, 0xff means "this part of the buffer is clear."

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

For what it's worth, these problems should go away if you upgrade to the upcoming X server stable releases: either 1.15.1 or 1.14.6.  (Those should be coming out any day now.)  KWin is erroneously getting an 8x multisampled visual/fbconfig due to a server-side GLX bug, and it really doesn't want one.

That said, I think winsys multisampling is still broken, so this is a real bug.  Upgrading the X server is probably the best path for users right now, while we figure out what's going on.

Another easier workaround in the meantime is to ask KWin to use EGL:

   KWIN_OPENGL_INTERFACE=egl kwin --replace &

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

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

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

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

Kenneth, could you point me to exact xserver commit(s) which should fix the bug?

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

(In reply to comment #14)
> Kenneth, could you point me to exact xserver commit(s) which should fix the
> bug?

Sure.  It's "glx: Clear new FBConfig attributes to 0 by default.":

http://cgit.freedesktop.org/xorg/xserver/commit/?id=96a28e9c914d7ae9b269f73a27b99cbd3c465ac8

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

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

Eric posted a Mesa patch which fixes the corruption/hangs:
http://lists.freedesktop.org/archives/mesa-dev/2014-April/057818.html

Apparently, it was indeed a problem with our multisample control buffer handling.  With that patch, window system multisampling works reliably (at least for me.)  Thank you all for the excellent data, and sorry for the trouble!

That said, KWin really should not be using 8x multisampling - it adds a lot of unnecessary overhead.  I'd still strongly recommend upgrading to X server 1.15.1 or 1.14.6, which fix the GLX bug which caused KWin to do this.  Or, you can continue working around that bug by using KWIN_OPENGL_INTERFACE=egl.

Any of the above should fix this issue.

commit 7ae870211ddc40ef6ed209a322c3a721214bb737
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Apr 14 16:52:43 2014 -0700

    i965: Fix buffer overruns in MSAA MCS buffer clearing.

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

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

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

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

KWIN_OPENGL_INTERFACE=egl or KWIN_OPENGL_INTERFACE=egl kwin --replace & do not work to me.

Downgrade to mesa 8 makes it work.

I am sorry for reopen it, but my original bug report (about graphical corruptions - white stripes #77256 ) has been marked as duplicate of this bug.

(In reply to comment #25)
> KWIN_OPENGL_INTERFACE=egl or KWIN_OPENGL_INTERFACE=egl kwin --replace & do
> not work to me.
> 
> Downgrade to mesa 8 makes it work.
> 
> I am sorry for reopen it, but my original bug report (about graphical
> corruptions - white stripes #77256 ) has been marked as duplicate of this
> bug.

Perhaps your KWin doesn't have EGL support, so that workaround fails.

The proper solution is to upgrade to Mesa 10.0.5, 10.1.1, or 10.2-rc1.  That will fix the actual driver bug.  If you upgrade to one of those releases, and still experience the problem, please reopen the bug.

I also highly recommend upgrading to X server 1.15.1 or 1.14.6.  It isn't strictly necessary, but without it, things will be slow.

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

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

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

Hi Kenneth, 

I upgraded my Ubuntu trusty to today's state of the xorg-edgers PPA:

xserver-xorg-core	2:1.15.1-0ubuntu2
xserver-xorg-video-intel	2:2.99.911+git20140507.18416b51-0ubuntu0ricotz~trusty
libegl1-mesa:amd64	10.3.0~git20140514.8a9f5ecd-0ubuntu0sarvatt~trusty
libgl1-mesa-dri:amd64	10.3.0~git20140514.8a9f5ecd-0ubuntu0sarvatt~trusty

$ glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0-devel
OpenGL version string: 3.0 Mesa 10.3.0-devel

I'm still experiencing problems. Garbage screen output disappeared, but the screen is stuck for 5-20 secs every 1-3 minutes.

The kernel ring buffer says:
[  333.738942] [drm] stuck on render ring
[  333.738951] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[  333.738952] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[  333.738953] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[  333.738954] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[  333.738955] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[  339.736311] [drm] stuck on render ring
[  339.736354] [drm:i915_context_is_banned] *ERROR* context hanging too fast, declaring banned!
[  348.720483] [drm] stuck on render ring
[  354.729941] [drm] stuck on render ring
[  360.727429] [drm] stuck on render ring
[  360.727558] [drm:i915_context_is_banned] *ERROR* context hanging too fast, declaring banned!
[  439.102608] init: tty1 main process ended, respawning
[  468.674648] [drm] stuck on render ring
[  647.707294] [drm] stuck on render ring
[  716.739191] [drm] stuck on render ring

So I'm still having trouble, even with xserver 1.15.1 and a recent mesa version.

Regards,
Benjamin

Created attachment 99107 [details]
cat /sys/class/drm/card0/error > error.txt

Hi Benjamin,

The batch buffer in your error state does not contain garbage - instead, it looks like you're hanging on a PIPE_CONTROL after a 3DPRIMITIVE.  Plus, you don't have the graphical corruption described here.  And you definitely have the fix for this bug.

So, I think you're hitting a different GPU hang unrelated to this report.  I've gone ahead and created bug #78751 to track your issue.

Closing this one again.

--Ken