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).
Created attachment 85225 [details] Another sample of corruption
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.
Can you check whether some of the kernel fixes for 3.12 (drm-intel-nightly) affect this?
Yes, I'll compile kernel from drm-intel-nightly and check
The bug still exists on kernel built from drm-intel-nightly branch(the last commit was b315fedf01ac717f1c2a5eaa6959335b6baf7150).
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))
Unfortunately, it not helps, screen still corrupts.
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?
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.
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.
*** 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.