Bug 68964

Summary: [ivb] Screen corruption in Chromium
Product: xorg Reporter: bay <bay>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED DUPLICATE QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
The screenshot
none
Another sample of corruption
none
The corruption and X -version none

Description bay 2013-09-05 06:07:36 UTC
Created attachment 85224 [details]
The screenshot

This happens 4-5 times per day on average. Screen corrupts not only in chromium, but also randomly in KDE workspace.

This happens especially often on http://cloud.feedly.com/ site.

Git bisect says that the first bad commit is d935912d9c13ec8cf4f641c55846714d4e9ba929, 2013-07-09, sna: Free the source reference after performing a BLT composite, -6/+14.

Reverting this commit in git master fixes this bug, but, probably, causes a memory leak(bug 66742).
Comment 1 bay 2013-09-05 06:08:46 UTC
Created attachment 85225 [details]
Another sample of corruption
Comment 2 Chris Wilson 2013-09-05 10:20:56 UTC
This looks like bug 66990, which came and went without a good resolution. Your bisect fits in with the theory that the GPU is missing a flush with the upload buffers (by reverting that commit you prevent it from reusing any upload buffer).

You have added some important info, I had presumed it was along the render copy paths, but this suggests that it is the blt copy.
Comment 3 Chris Wilson 2013-09-05 10:55:21 UTC
Can you check whether some of the kernel fixes for 3.12 (drm-intel-nightly) affect this?
Comment 4 bay 2013-09-05 11:01:14 UTC
Yes, I'll compile kernel from drm-intel-nightly and check
Comment 5 bay 2013-09-05 12:23:40 UTC
The bug still exists on kernel built from drm-intel-nightly branch(the last commit was b315fedf01ac717f1c2a5eaa6959335b6baf7150).
Comment 6 Chris Wilson 2013-09-05 13:37:00 UTC
Had an idea, can you please try this quick patch:

diff --git a/src/sna/gen7_render.c b/src/sna/gen7_render.c
index e92a83b..be7dda0 100644
--- a/src/sna/gen7_render.c
+++ b/src/sna/gen7_render.c
@@ -1283,7 +1283,7 @@ gen7_bind_bo(struct sna *sna,
                 (height - 1) << GEN7_SURFACE_HEIGHT_SHIFT);
        ss[3] = (bo->pitch - 1) << GEN7_SURFACE_PITCH_SHIFT;
        ss[4] = 0;
-       ss[5] = is_scanout ? 0 : is_hsw(sna) ? 5 << 16 : 3 << 16;
+       ss[5] = (is_scanout || bo->io) ? 0 : is_hsw(sna) ? 5 << 16 : 3 << 16;
        ss[6] = 0;
        ss[7] = 0;
        if (is_hsw(sna))
Comment 7 bay 2013-09-05 18:19:14 UTC
Unfortunately, it not helps, screen still corrupts.
Comment 8 bay 2013-09-05 18:49:14 UTC
Created attachment 85278 [details]
The corruption and X -version

This is a part of X -version output:

X.Org X Server 1.14.2.902 (1.14.3 RC 2)
Release Date: 2013-08-22
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.10.9-gentoo x86_64 Gentoo
Current Operating System: Linux BaysGentooNotebook 3.11.0-rc7+ #1 SMP Thu Sep 5 18:05:49 YEKT 2013 x86_64

After I recompiled the xorg-server on 3.11.0-rc7+ I can't reproduce the bug. I've tested with several video driver versions and never saw the corruption. Then I returned to 3.10.9 kernel and recompiled xorg-server once again and bug reapeared. After this I recompiled xorg-server on 3.11.0-rc7+ once more again and bug disappeared again.

It's a bit odd. Can X server behavior depend on version of kernel on compilation time?
Comment 9 Chris Wilson 2013-09-06 09:08:54 UTC
It is possible that you install a different set of kernel headers which changes how userspace behaves (enables different feature paths etc), I don't think X has such subtleties. (The DDX does, but it uses local definitions to isolate itself from random versions of the kernel headers.)

I would suggest that it is a timing issue - as far as I can tell it requires reusing the wrong buffer at the wrong time to trigger.

I've gone ahead and pushed the patch the patch to disable MOCS for staging upload buffers.
Comment 10 bay 2013-09-07 08:06:52 UTC
It seems you are right - after two days of using, I've just seen a screen corruption, but not in the same place as usual.

I updated video driver from git, the corruption is still here.
Comment 11 Chris Wilson 2013-09-08 10:51:51 UTC

*** This bug has been marked as a duplicate of bug 66990 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.