| Summary: | [BDW-Y bisected] Screen flicker when start X with FBC enable | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | ye.tian <yex.tian> | ||||||
| Component: | DRM/Intel | Assignee: | Paulo Zanoni <przanoni> | ||||||
| Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | christophe.prigent, intel-gfx-bugs, przanoni | ||||||
| Version: | unspecified | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | BDW | i915 features: | display/FBC | ||||||
| Attachments: |
|
||||||||
|
Description
ye.tian
2015-04-28 09:22:19 UTC
Created attachment 115395 [details]
dmesg info
Created attachment 115396 [details]
Xorg.0.log info
Could you double check the bisect? That commit only changes DRIVER_DATE, which shouldn't really change the driver behavior. Bisect shows, the first bad commit is dbef0f1. commit dbef0f15b5c83231dacb214dbf9a6dba063ca21c Author: Paulo Zanoni <paulo.r.zanoni@intel.com> AuthorDate: Fri Feb 13 17:23:46 2015 -0200 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Tue Mar 17 22:29:56 2015 +0100 drm/i915: add frontbuffer tracking to FBC Kill the blt/render tracking we currently have and use the frontbuffer tracking infrastructure. Don't enable things by default yet. v2: (Rodrigo) Fix small conflict on rebase and typo at subject. v3: (Paulo) Rebase on RENDER_CS change. v4: (Paulo) Rebase. v5: (Paulo) Simplify: flushes don't have origin (Daniel). Also rebase due to patch order changes. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> If you're using one of the SDVs, please boot the machine and go to the BIOS Intel Advanced Menu -> System Agent (SA) Configuration -> Graphics Configuration -> Then please change the "DVMT pre-allocated" size to something big (it's probably 32mb, and setting to 64mb should be enough). Then boot and see if the problem is gone. Don't forget to set the value back to 32mb after testing :) This isn't really a "fix", but just a way to confirm that something is using the top of stolen memory. Timeout, closing. Please reopen if the problem persists with latest kernels and the config changes from comment #5. |
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.