| Summary: | [SNB bisected]Fail to type characters in xterm on a HuronRiver(0116 rev 09) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | meng <mengmeng.meng> | ||||||||||
| Component: | DRM/Intel | Assignee: | Jesse Barnes <jbarnes> | ||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | high | CC: | jbarnes | ||||||||||
| Version: | unspecified | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux (All) | ||||||||||||
| Whiteboard: | |||||||||||||
| i915 platform: | i915 features: | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
meng
2011-02-18 02:56:28 UTC
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.