Summary: | [ivb] Screen corruption in Chromium | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | bay <bay> | ||||||||
Component: | Driver/intel | Assignee: | 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
bay
2013-09-05 06:07:36 UTC
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.