Created attachment 43514 [details] dmesg System Environment: -------------------------- Platform: HuronRiver(only) Libdrm: (master)2.4.23-8-g36d4939343d8789d9066f7245fa2d4fe69119dd8 Mesa: (master)f55d027ac2e0423eba5d0664cc36668520597703 Xf86_video_intel: (master)2.14.0-26-g23f9b14df7c102c1036134835dd5d1a508059858 Cairo: (master)4d4056872db94573183473610ad1d81d5439fdc6 Kernel: (drm-intel-next) 9035a97a32836d0e456ddafaaf249a844e6e4b5e Bug detailed description: ------------------------- When typing characters in xterm on a HuronRiver(0116 rev 09), it is not displayed.If moving the mouse,the characters that we has just typed will appear. The issue doesn't exist in gnome-desktop.Pls see attached dmesg. Specifically: 1.It works fine on Sugarbay and other HuronRiver(0126 rev08). 2.It's kernel regression.9c04f015ebc2cc2cca5a4a576deb82a311578edc is the first bad commit. commit 9c04f015ebc2cc2cca5a4a576deb82a311578edc Author: Yuanhan Liu <yuanhan.liu@linux.intel.com> Date: Wed Dec 15 15:42:32 2010 +0800 drm/i915: Add frame buffer compression on Sandybridge Add frame buffer compression on Sandybridge. The method is similar to Ironlake, except that two new registers of type GTTMMADR must be written with the right fence info. Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reproduce steps: ------------------------- 1.xinit&
Are you absolutely certain, as we fixed this once already: commit 4efe070896e1f7373c98a13713e659d1f5dee52a Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Jan 18 11:25:41 2011 -0800 drm/i915: make the blitter report buffer modifications to the FBC unit Without this change, blits to the front buffer won't invalidate FBC state, causing us to scan out stale data. Make sure we update these bits on every FBC enable, since they may get clobbered if we shut off the display. References: https://bugzilla.kernel.org/show_bug.cgi?id=26932 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> and I don't see the effect here.
Test with Kernel: (drm-intel-next)4efe070896e1f7373c98a13713e659d1f5dee52a,the problem exists too.
What are the values of the FBC registers when this failure occurs? Also register 0x42020 may contain clues.
Also, Chris, since this is xterm, are we hitting sw fallbacks and going through a CPU fence register for these writes? Or will we still use the blit engine to upload them into the front buffer on this path (as we would for gnome-terminal, which presumably goes through an XCopyArea or similar).
Created attachment 43681 [details] [review] flush blt ring and set notify bit Can you try this patch?
Created attachment 43682 [details] [review] fix flush_dw usage Oops, try this one instead, I was missing MI_FLUSH_DW args in the last one.
(In reply to comment #6) > Created an attachment (id=43682) [details] > fix flush_dw usage > Oops, try this one instead, I was missing MI_FLUSH_DW args in the last one. Test in (drm-intel-next)f4166442e7533ca2668d639d939b1bbdb8e6b423 with this patch,the problem still exists.Register 0x42020:0x100000A0,and by cat i915_fbc_status:FBC enabled.
(In reply to comment #4) > Also, Chris, since this is xterm, are we hitting sw fallbacks and going through > a CPU fence register for these writes? Or will we still use the blit engine to > upload them into the front buffer on this path (as we would for gnome-terminal, > which presumably goes through an XCopyArea or similar). Yeah, xterm may either be using PolyImageGlyphs or RenderGlyphs depending upon the font and user configuration. And so it may be accessing the frontbuffer via either direct CPU writes or (effectively) CopyArea BLTs.
Created attachment 43723 [details] [review] add missing SNB FBC bits Ok, still missing some bits. Can you try this one? It adds a couple of chicken bits to 0x42020 that are supposed to be needed.
(In reply to comment #9) > Created an attachment (id=43723) [details] > add missing SNB FBC bits > Ok, still missing some bits. Can you try this one? It adds a couple of > chicken bits to 0x42020 that are supposed to be needed. Test in commit 710f957 with this patch(id=43723),the problem still exists.And register 0x42020:0x100003A0.
*** This bug has been marked as a duplicate of bug 33487 ***
Closing old verified.
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.