Bug 36326 - [uxa 915GM] Characters sometimes have horizontal lines through them (glyph font corruption)
[uxa 915GM] Characters sometimes have horizontal lines through them (glyph fo...
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
git
x86 (IA32) Linux (All)
: medium major
Assigned To: Chris Wilson
Intel GFX Bugs mailing list
:
: 37782 39851 49396 55881 65433 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-17 07:06 UTC by Sitsofe Wheeler
Modified: 2015-04-08 15:24 UTC (History)
23 users (show)

See Also:


Attachments
Screenshot of glyph corruption (227.94 KB, image/png)
2011-04-17 07:28 UTC, Sitsofe Wheeler
no flags Details
Workaround glyph corruption (1.01 KB, patch)
2011-04-19 15:14 UTC, Sitsofe Wheeler
no flags Details | Splinter Review
Xorg log taken after crash (24.68 KB, text/plain)
2011-06-05 05:09 UTC, Sitsofe Wheeler
no flags Details
i915_error_state after crash (695.60 KB, text/plain)
2011-06-05 05:10 UTC, Sitsofe Wheeler
no flags Details
Use pot size, not multiple-of-two tile height (2.31 KB, patch)
2011-06-05 05:32 UTC, Chris Wilson
no flags Details | Splinter Review
i915_error_state for 3.0.0-rc1 (without pot patch) (695.42 KB, text/plain)
2011-06-05 05:47 UTC, Sitsofe Wheeler
no flags Details
i915_error_state for 3.0.0-rc1 (with pot patch) (695.42 KB, text/plain)
2011-06-05 05:56 UTC, Sitsofe Wheeler
no flags Details
Fix unfenced alignment on pre-g33 (4.57 KB, patch)
2011-06-05 06:30 UTC, Chris Wilson
no flags Details | Splinter Review
915_error_state after fix unfenced alignment on pre-g33 patch (800.81 KB, text/plain)
2011-06-05 06:41 UTC, Sitsofe Wheeler
no flags Details
915_error_state after Y-tiling DDX patch (758.67 KB, text/plain)
2011-06-05 07:13 UTC, Sitsofe Wheeler
no flags Details
Flush around glyph updates (2.89 KB, patch)
2012-12-21 12:09 UTC, Chris Wilson
no flags Details | Splinter Review
Flush around glyph updates (2.87 KB, patch)
2012-12-21 12:10 UTC, Chris Wilson
no flags Details | Splinter Review
Disable glyph cache (950 bytes, patch)
2012-12-21 19:18 UTC, Sitsofe Wheeler
no flags Details | Splinter Review
Screenshot of patched driver with filled in glyphs (66.05 KB, image/png)
2012-12-21 21:36 UTC, Sitsofe Wheeler
no flags Details
Screenshot 2 of patched driver with filled in glyphs (254.82 KB, image/png)
2012-12-21 22:36 UTC, Sitsofe Wheeler
no flags Details
Screenshot 1 of 5, terminal filled with X's, corruption changes after scrot (93.39 KB, text/plain)
2014-02-10 00:39 UTC, linux.testing.marantz
no flags Details
Screenshot 1 of 5, terminal filled with X's, corruption changes after scrot (93.39 KB, image/png)
2014-02-10 00:41 UTC, linux.testing.marantz
no flags Details
Screenshot 2 of 5, terminal filled with X's, corruption changes after scrot (96.78 KB, image/png)
2014-02-10 00:42 UTC, linux.testing.marantz
no flags Details
Screenshot 3 of 5, terminal filled with X's, corruption changes after scrot (98.39 KB, image/png)
2014-02-10 00:43 UTC, linux.testing.marantz
no flags Details
Screenshot 4 of 5, terminal filled with X's, corruption changes after scrot (100.02 KB, image/png)
2014-02-10 00:44 UTC, linux.testing.marantz
no flags Details
Screenshot 5 of 5, terminal filled with X's, corruption changes after scrot (104.46 KB, image/png)
2014-02-10 00:45 UTC, linux.testing.marantz
no flags Details
Log files dmesg + Xorg,0,log showing machine info for screenshots above (83.92 KB, text/plain)
2014-02-10 00:49 UTC, linux.testing.marantz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sitsofe Wheeler 2011-04-17 07:06:25 UTC
Description of the problem:
With the soon to be released distros graphical corruption occasionally appears on font characters - everywhere a corrupted character of that size is it will be corrupted the same way.

Steps to reproduce:
1. Start computer.
2. Start a gnome-terminal .
3. Type
echo "import string; print string.printable" | python
4. Press Ctrl-"+" several times.
5. Press Ctrl-"-" several times.
6. Go to step 4.

Expected results:
Text to look normal as it is resized.

Actual results:
Sometimes characters will appear to have a line through them.

How reproducible is the problem?
Somewhat reproducible but only on an EeePC 900.

Version information:
Ubuntu 11.04
xorg 1:7.6+4ubuntu1
xserver-xorg-video-intel 2:2.14.0-4ubuntu6
linux-image-2.6.38-7-generic 2.6.38-7.39

Fedora 15
xorg-x11-server-Xorg-1.10.0-7.fc15.i686
xorg-x11-drv-intel-2.14.0-4.fc15.i686
kernel-2.6.38.2-9.fc15.i686

00:00.0 Host bridge [0600]: Intel Corporation Mobile 915GM/PM/GMS/910GML
Express Processor to DRAM Controller [8086:2590] (rev 04)

Additional Information:
Unreproducible on a machine with a 945GM/GMS/GME, 943/940GML (rev 03)
Comment 1 Sitsofe Wheeler 2011-04-17 07:28:48 UTC
Created attachment 45730 [details]
Screenshot of glyph corruption

As I'm only seeing this issue on LiveCDs (my Ubuntu 10.04 setup with an old xorg but a 2.6.38 kernel seems fine) testing fixes could be tricky for the foreseeable future...
Comment 2 Sitsofe Wheeler 2011-04-17 07:35:39 UTC
I will also note this happens with gnome-shell, compiz or metacity (although it seems to happen a bit sooner/more frequently with gnome-shell and Unity desktops).
Comment 3 Chris Wilson 2011-04-17 07:55:27 UTC
For 915GM it is important to test with 2.15.0 as well to rule out one source of tiling corruption.
Comment 4 Sitsofe Wheeler 2011-04-17 09:27:53 UTC
A somewhat painful Ubuntu live CD upgrade to xserver-xorg-video-intel 2:2.15.0+git20 shows the same problem (Xorg.0.log shows it it is using 2.15.0 too)...
Comment 5 Chris Wilson 2011-04-17 11:38:17 UTC
Thanks Sitsofe. I can now cry myself to sleep.
Comment 6 Sitsofe Wheeler 2011-04-17 23:43:23 UTC
Some additional information (although I'm not sure how comforting it's going to be):

Ubuntu 10.10 also exhibits the same behaviour (but only after I switched from compiz to metacity) and has the following packages:
xorg 1:7.5+6ubuntu3
xserver-xorg-video-intel 2:2.12.0-1ubuntu5
linux-image 2.6.35.28.36

My Ubuntu 10.04 setup with a 2.6.38 kernel does not show the problem with the following packages:
xorg 1:7.5+5ubuntu1
xserver-xorg-video-intel 2:2.9.1-3ubuntu5
Comment 7 Sitsofe Wheeler 2011-04-19 12:37:44 UTC
Another data point - the problem doesn't seem to occur with Fedora 13:
xorg-x11-server-Xorg-1.8.0-12.fc13.i686
xorg-x11-drv-intel-2.11.0-4.fc13.i686
kernel-2.6.33.3-85.fc13.i686

So it appears that the problem was inserted in the 2.12 release of the Intel DRM module / 2.6.34-2.6.35 release of the kernel.
Comment 8 Sitsofe Wheeler 2011-04-19 15:12:17 UTC
(Numerous bisections later...)

The problem appears to have been introduced in the following commit:

commit f05dd2f09cac422c423dae8f9b8e2be13df05a8f
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Feb 26 13:32:11 2010 -0800

    drm/i915: Don't bother with the BKL for GEM ioctls.
    
    We probably don't need it for most of the other driver ioctls as well,
    but we explicitly did locking when doing the GEM pieces.  On CPU-bound
    graphics tasks, the BKL was showing up as 1-2% of CPU time.
    
    Signed-off-by: Eric Anholt <eric@anholt.net>

I've narrowed it down to two lines in drivers/gpu/drm/i915/i915_dma.c:

       DRM_IOCTL_DEF(DRM_I915_GEM_SET_TILING, i915_gem_set_tiling, DRM_UNLOCKED),
       DRM_IOCTL_DEF(DRM_I915_GEM_GET_TILING, i915_gem_get_tiling, DRM_UNLOCKED),

If the last parameter is 0 instead of DRM_UNLOCKED the problem goes away even on the latest drm-intel-fixes branch.
Comment 9 Sitsofe Wheeler 2011-04-19 15:14:10 UTC
Created attachment 45831 [details] [review]
Workaround glyph corruption

It's blunt but it seems to work. I haven't done tests to work out if only one of the lines is needed...
Comment 10 Sitsofe Wheeler 2011-04-19 17:02:53 UTC
Sadly the above patch did nothing to solve the problem on a Fedora 15 live CD. Rolling back to a 2.6.28 kernel with the above patch didn't help either. Weird and frustrating.
Comment 11 jules9112 2011-04-25 01:57:34 UTC
I'd like to confirm that this bug manifests itself for me as well, on an Asus EEE 900, on every recent distro I've tried. It's not only reproducible but happens all the time. It's extremely jarring, sometimes half the glyphs get corrupted resulting in barely readable text.
Comment 12 Sitsofe Wheeler 2011-04-25 12:43:57 UTC
The symptoms described in this bug are very similar to those described in the closed bug #34662 ...
Comment 13 Sitsofe Wheeler 2011-04-25 13:58:37 UTC
This may also be related to bug #35557.

For what it's worth, there is some more anecdotal evidence that this was introduced in the 2.12 release of the Intel DRM module - http://forums.opensuse.org/english/get-technical-help-here/hardware/442680-font-corruption-x-anyone-else-seeing.html#post2272576 talks about how switching to intellegacy in OpenSUSE resolved the problem for the commenter. http://askubuntu.com/questions/29626/font-corruption-lines-through-characters talks about how it started happening in Ubuntu 10.10 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600474#5 describes how it started happening after upgrading from xserver-xorg-video-intel 2:2.9.1-4
2:2.12.0+shadow-2 to xserver-xorg-video-intel 2:2.12.0+shadow-2
2:2.13.0-1 .
Comment 14 jules9112 2011-04-25 22:19:51 UTC
bug #35557 may or may not be related, but it's interesting that 1.) He's using a 945GM 2.) He's having vertical corrupted lines in glyphs. It seems that the 915GM only exhibits horizontal corruption (which by itself is very weird). By the way, it would be so great to finally put a nail in the coffin of this one, so please tell me if I can help with testing in any way.
Comment 15 jules9112 2011-04-26 01:36:34 UTC
Something possibly useful: switching the acceleration method from UXA to EXA seems to reduce the corruption significantly for me (one or two letters corrupted instead of a dozen), although unfortunately it's still there.
Comment 16 Sitsofe Wheeler 2011-04-27 03:09:56 UTC
jules9112:
Bug #35995 sounds pretty much identical this bug (horizontal lines, 915GM, driver is 2.14+) and has been marked a duplicate of bug #35557 .

If someone who sees the problem can find a way of bisecting the intel driver versions between 2.11 and 2.12 we might at least be able to find out exactly which change introduced the problem. Once it has been narrowed down by a tester, the hope is that an expert can justify looking at the problem because finding a solution will hopefully take them less time than it would have done before...
Comment 17 Sitsofe Wheeler 2011-05-15 06:55:32 UTC
I've just done an Ubuntu 11.04 install and tested with different kernels and I find 2.6.33 is OK, 2.6.34 is a problem. The bisection between .33 and .34 is as follows:

# bad: [e40152ee1e1c7a63f4777791863215e3faa37a86] Linus 2.6.34
# good: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33
git bisect start 'v2.6.34' 'v2.6.33' '--' 'drivers/gpu/drm/i915/'
# good: [ae3db24aab398fb5f985696c12362eb12ef65812] drm/i915: extract fence stealing code
git bisect good ae3db24aab398fb5f985696c12362eb12ef65812
# bad: [8956c8bba5b11b3d3aec000e6c6184943011a8d4] drm/i915: Set up the documented clock gating on Sandybridge and Ironlake.
git bisect bad 8956c8bba5b11b3d3aec000e6c6184943011a8d4
# good: [1c62233508ef7104f8a78e571fdf5c72d0dc0200] Merge branch 'gpu-switcher' of /ssd/git//linux-2.6 into drm-next-stage
git bisect good 1c62233508ef7104f8a78e571fdf5c72d0dc0200
# bad: [71cf39b117d5aa817a4693f4478397e6b04bee25] drm/i915: Enable VS timer dispatch.
git bisect bad 71cf39b117d5aa817a4693f4478397e6b04bee25
# bad: [5d9391628e8eb3b0830697697a95bfd0c3c35b9e] drm/i915: remove an unnecessary wait_request()
git bisect bad 5d9391628e8eb3b0830697697a95bfd0c3c35b9e
# bad: [f05dd2f09cac422c423dae8f9b8e2be13df05a8f] drm/i915: Don't bother with the BKL for GEM ioctls.
git bisect bad f05dd2f09cac422c423dae8f9b8e2be13df05a8f

This is the same result as comment #8. Further, putting

Section "Device"
	Identifier      "Intel 915GM"
	Driver		"intel"
	Option 		"Tiling" "false"
EndSection

in /etc/X11/xorg.conf doesn't stop the problem from occurring.
Comment 18 Sitsofe Wheeler 2011-05-16 14:24:05 UTC
Using a 2.6.36 kernel with Fedora 13 showed the problem. Using the 2.10 DDX driver with a newer kernel also showed the problem so it looks like this issue was masked with kernels <= 2.6.33. The thing to note is that Ubuntu 10.04 (with a 2.9 DDX) does not show the problem with newer kernels.
Comment 19 Sitsofe Wheeler 2011-05-22 08:16:09 UTC
A quick recap:
Occurs with Intel DDX 2.10+ (tested up to .15) with Kernel 2.6.34+ (tested up to .39).
Reported affecting a 915GM and a 945G.
Setting 

Section "Device"
    Identifier "Intel"
    Driver "intel"
    Option "DebugWait" "true"
EndSection

in xorg.conf works around the problem in at least two cases.
Setting Tiling to false in xorg.conf does not resolve the problem.
Comment 20 Matej Cepl 2011-06-03 03:36:39 UTC
Closing our bug https://bugzilla.redhat.com/708849 against this one.
Comment 21 Sitsofe Wheeler 2011-06-05 04:20:25 UTC
OK I finally had time to test the SNA branch up at http://cgit.freedesktop.org/~ickle/xf86-video-intel/ . The only thing changed from a Fedora 15 live CD was the intel_drv.so .

The good news
This didn't show the corruption on font resizing at the terminal.

The bad news
While just typing at the terminal the entire prompt would sometimes disappear. Sometimes only one pixel of row of letters could be seen. When doing printscreen to try and capture a screenshot everything would fix itself just before the screenshot was taken. After a bit the entire system would lock up and the hangcheck timer would elapse. VTs and plymouth continued to work though. All this behaviour happens fairly quick - within 5 minutes of starting X.
Comment 22 Chris Wilson 2011-06-05 04:28:10 UTC
Sitsofe, just to be a nuisance, can you try again with xf86-video-intel.git and --enable-sna

And then attach the usual the suspects (Xorg.log and i915_error_state), thanks!
Comment 23 Sitsofe Wheeler 2011-06-05 05:09:33 UTC
Created attachment 47554 [details]
Xorg log taken after crash

Mainline xf86-video-intel.git still blows up.
Comment 24 Sitsofe Wheeler 2011-06-05 05:10:04 UTC
Created attachment 47555 [details]
i915_error_state after crash
Comment 25 Chris Wilson 2011-06-05 05:32:26 UTC
Created attachment 47556 [details] [review]
Use pot size, not multiple-of-two tile height
Comment 26 Sitsofe Wheeler 2011-06-05 05:47:02 UTC
Created attachment 47558 [details]
i915_error_state for 3.0.0-rc1 (without pot patch)
Comment 27 Sitsofe Wheeler 2011-06-05 05:56:44 UTC
Created attachment 47559 [details]
i915_error_state for 3.0.0-rc1 (with pot patch)
Comment 28 Chris Wilson 2011-06-05 06:30:28 UTC
Created attachment 47560 [details] [review]
Fix unfenced alignment on pre-g33
Comment 29 Sitsofe Wheeler 2011-06-05 06:41:24 UTC
Created attachment 47561 [details]
915_error_state after fix unfenced alignment on pre-g33 patch
Comment 30 Sitsofe Wheeler 2011-06-05 07:13:57 UTC
Created attachment 47563 [details]
915_error_state after Y-tiling DDX patch
Comment 31 Sitsofe Wheeler 2011-06-06 00:50:48 UTC
The combination of an updated SNA based DDX and the latest kernel patch seems to resolve all font corruption problems I have been seeing. However copying the binary DDX compiled for Fedora 15 to an Ubuntu 11.04 install showed that corruption around the border of the screen was happening when show all desktops (windows-s) was used (probably unrelated to this bug though).

Note: the kernel patch alone is not enough to stop font corruption.
Comment 32 Sitsofe Wheeler 2011-06-06 22:57:34 UTC
The more I think about this, the more I feel this bug report should be marked fixed as soon as all the patches in it land - the latest intel.git + kernel changes fix the font problem but at a price. The DDX SNA rewrite has brought new issues (which should be in separate bug reports as they may be unrelated to this one) that make for an unpleasant experience at present.

Before this bug is closed I guess it is worth checking: is it possible for a patch to be generated for pre SNA xorg drivers/older kernels (as found in Ubuntu 11.04/Fedora 15)? If not, users seeing the font problem on said distros will have to use the DebugWait workaround until newer distros (11.08/16) land...
Comment 33 Chris Wilson 2011-06-07 00:31:10 UTC
Yes, I'm planning to disable tiling on pre-G33 boxes without the kernel patch. That should prevent the hang (but at a noticeable performance hit). Sorry.

Sitsofe, please file those SNA bugs soon. :)
Comment 34 Sitsofe Wheeler 2011-06-07 01:41:38 UTC
SNA rewrite issues have been broken out into bug 38021 . If I ever find the time I will try and split that bug into smaller pieces...
Comment 35 Sitsofe Wheeler 2011-07-19 08:20:57 UTC
There is a rumour going round that this is actually Bug #28798 . I haven't had a chance to confirm or deny this...
Comment 36 Florian Mickler 2011-07-31 11:44:50 UTC
A patch referencing this bug report has been merged in Linux v3.0:

commit e28f87116503f796aba4fb27d81e2c3d81966174
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 18 13:11:49 2011 -0700

    drm/i915: Fix unfenced alignment on pre-G33 hardware
Comment 37 Jason Tibbitts 2011-08-04 12:57:05 UTC
Just a note that e28f87116503f796aba4fb27d81e2c3d81966174 does not appear to have any effect for me.  I'm running a 3.0 kernel (with the 3.0.1 queue applied), have verified that the patch is included, and I still see the corruption.

For reference, this is i945:

00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 817a
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at dfd00000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at b800 [size=8]
        Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Memory at dfd80000 (32-bit, non-prefetchable) [size=256K]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Kernel driver in use: i915
        Kernel modules: i915

X driver is the stock Fedora 15 version: xorg-x11-drv-intel-2.15.0-5.fc15.x86_64.  I'll try the 2.15.901 code next just to see what happens.
Comment 38 Jason Tibbitts 2011-08-04 14:54:05 UTC
Just to be thorough, I'll report that updating to server version 10.1.99.1 and Intel driver version 2.15.901 does not appear have any effect at all on the problem.

However, according to other information on this ticket I'd expect to see this problem on Fedora 14 (with xorg-x11-drv-intel-2.12.0-6.fc14.1.x86_64 and kernel-2.6.35.13-92.fc14.x86_64) but everything is completely fine there.  That F14 kernel does, however, carry a few i915-related patches; I'm not able to tell if they have any bearing on the issue.

Regardless, this looks like an annoyingly complex issue.
Comment 39 Sitsofe Wheeler 2011-08-05 02:08:51 UTC
Jason:

The kernel patch alone does not fix the problem (see comment #31). I needed an intel driver that was using the "new" SNA paths in addition to the kernel patch for the problem to be solved. This is consistent with what you are reporting because Fedora 15's intel driver is not using the SNA path (the SNA path isn't on by default in the intel drivers). If you can get hold of SNA enabled drivers for Fedora 15 let me know as I'd like to test them too (at the moment I have to hand compile has issues with older xorgs)...

I admit I am baffled by the fact that you do not see the problem on Fedora 14 though. Perhaps you are using a different desktop in Fedora 15 to what you were using in 14?

Oh and does the workaround described in comment #19 make any difference to your problem?
Comment 40 Jason Tibbitts 2011-08-05 05:43:26 UTC
Unfortunately I am not entirely sure how to get an SNA-based DDX; I assumed that the 2.15.901 driver would be such, but perhaps that needs to be enabled at build time.

I can state that if this problem is present on F14, I haven't seen it and no user has reported it.  I have 30+ identical desktops with this hardware configuration.  It is certainly possible that some other difference masks the problem in F14; there is plenty of updated software and unfortunately you can't just go back to the old kernel and X on an F15 machine to check.  Both logins are with the same account to a generic KDE desktop and it's pretty trivial to make it happen on the F15 machine; many times it's even visible on the login screen.

I might be able to take an F14 machine and go forward with X and the kernel to see if one breaks; I can try to allocate some time to try that out next week.

As for the debugwait trick, I'll try that out today if I can find some time.
Comment 41 Jason Tibbitts 2011-08-05 10:26:04 UTC
OK, in my testing the DebugWait trick appears to work fine (with the 3.0.1 kernel and the 2.15.901 non-SNA driver, at least; I haven't time to drop back to the stock F15 packages today).  I guess it's slower but I don't really notice much difference.

I can try a SNA build next week; I expect that it will solve the problems but I'm not sure if it's supposed to be ready for deployment yet.
Comment 42 Bryce Harrington 2012-02-29 17:56:35 UTC
Reportedly still happening in Ubuntu Precise:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608
Comment 43 Sitsofe Wheeler 2012-04-07 08:54:48 UTC
I can confirm that the issue is still occurring (and is reproducible within 30 seconds using the original steps) in the Fedora 17 and Ubuntu 12.04 betas (which are using v2.18 and v2.17 of the intel driver). The DebugWait option still resolves the problem too. None of the other options (DebugFlushBatches or DebugFlushCaches true, Tiling false) resolve the issue.

Using xorg-edgers ( https://launchpad.net/~xorg-edgers/+archive/ppa ) and sarvatt's intel-sna branch ( https://launchpad.net/~sarvatt/+archive/intel-sna ) also resolves the issue.
Comment 44 Paul Menzel 2012-07-24 11:45:09 UTC
The Debian BTS contains the following two reports regarding this issue.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614296
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675734
Comment 45 Paul Menzel 2012-07-24 11:46:31 UTC
In the Red Hat Bugzilla this issue is reported as #704959 [1].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=704959
Comment 46 Paul Menzel 2012-07-24 12:35:02 UTC
(In reply to comment #44)
> The Debian BTS contains the following two reports regarding this issue.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614296
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675734

As written in the Debian reports using the SNA backend fixes this issue on my Eee PC 701 4G system.
Comment 47 Paul Menzel 2012-07-24 12:36:50 UTC
There are also some reports suggesting this happens with 945GM/GMS too.

Could the bug title be updated please to reflect that please?
Comment 48 Paul Menzel 2012-07-24 12:38:30 UTC
In #intel-gfx Chris Wilson also suggested to try the options

    Option "DebugFlushBatches" "1"

and

    Option "DebugFlushWait" "1"

together and separately with the default backend (non SNA). Maybe someone in here can report any success with this.
Comment 49 Paul Menzel 2012-07-24 16:39:05 UTC
15:08 < danvet> PaulePanter, could be swizzling corruption, we've fixed such a bug for i915g recently I think
15:09 < danvet> 3.4 should have the fix, so retesting with that one might be worth a shot

Could someone please try Linux kernel 3.4 and also 3.5? In Debian they should be in the experimental repositories and also on snapshot.debian.org [1]. Due to disk space limitations it is not very feasible on the Eee PC 701 4G.

Please remember to increase the appropriate log levels [2].


[1] http://snapshot.debian.org/package/linux/3.4.4-1~experimental.1/
[2] http://intellinuxgraphics.org/how_to_report_bug.html
Comment 50 Sitsofe Wheeler 2012-07-24 19:03:15 UTC
As mentioned earlier Ubuntu 12.04 with intel drm 2.17 doesn't see any change in the issue when using DebugFlushBatches. DebugFlushWait isn't a recognised option.
Comment 51 Paul Menzel 2012-07-24 20:22:19 UTC
(In reply to comment #50)
> As mentioned earlier Ubuntu 12.04 with intel drm 2.17 doesn't see any change in
> the issue when using DebugFlushBatches.

Alright. I have to test this.

> DebugFlushWait isn't a recognised option.

I am sorry. This should be `DebugWait`. I should have checked the manual `man intel`.
Comment 52 Paul Menzel 2012-07-24 20:29:06 UTC
(In reply to comment #43)
> I can confirm that the issue is still occurring (and is reproducible within 30
> seconds using the original steps) in the Fedora 17 and Ubuntu 12.04 betas
> (which are using v2.18 and v2.17 of the intel driver).

This issue is also reproducible with xserver-xorg-video-intel 2:2.19.0-4.

> The DebugWait option still resolves the problem too.

I just tested that and it also seems – only one try – to solve this problem on my Eee PC 701 4G system.

> None of the other options (DebugFlushBatches or DebugFlushCaches true,
> Tiling false) resolve the issue.
> 
> Using xorg-edgers ( https://launchpad.net/~xorg-edgers/+archive/ppa ) and
> sarvatt's intel-sna branch ( https://launchpad.net/~sarvatt/+archive/intel-sna
> ) also resolves the issue.

Does that automatically enable SNA? Can you just try the intel-sna? In (at least) 2.19.0 you can also enable SNA by an option to the driver (in Debian).

    $ more /etc/X11/xorg.conf.d/99-custom.conf
    Section "Device"
         Identifier "Device0"
         Driver "intel"
         Option "AccelMethod" "sna"
    EndSection
Comment 53 Paul Menzel 2012-07-24 20:42:53 UTC
On #intel-gfx suggested having to use `DebugWait` is an indicator of a Linux kernel bug.

    20:34 < ickle> that hints towards a kernel bug
    20:34 < ickle> of the sort fixed by the unfenced blt patch

This should be in Linux 3.4 and definitely in 3.5. So it would be great if somebody could test this.
Comment 54 Sitsofe Wheeler 2012-07-24 20:49:11 UTC
I agree that SNA resolves the issue (see comment #31).

I've just tested a 3.5 kernel with Ubuntu 12.04's 2.17 DDX and the issue remained (so newer kernels alone don't seem to help).
Comment 55 Armands Liepins 2012-10-21 09:22:48 UTC
Still happens on fedora 17.

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
kernel-PAE-3.6.2-4.fc17.i686
xorg-x11-server-Xorg-1.12.3-2.fc17.i686
xorg-x11-drv-intel-2.20.8-1.fc17.i686
mesa-dri-drivers-8.0.4-1.fc17.i686

With sna accel X crashes occasionally.
Comment 56 Chris Wilson 2012-10-21 09:27:10 UTC
(In reply to comment #55)
> With sna accel X crashes occasionally.

Tell me more. New bug, and make sure you have 2.20.12.
Comment 57 Armands Liepins 2012-10-22 07:22:52 UTC
(In reply to comment #56)
> (In reply to comment #55)
> > With sna accel X crashes occasionally.
> 
> Tell me more. New bug, and make sure you have 2.20.12.

Unfortunately fedora 17 has only 2.20.10 in updates-testing. Have to compile myself then.
Comment 58 Armands Liepins 2012-10-22 17:59:34 UTC
According the changelog there are no changes related to sna in 2.20.11 and 2.20.12, but 2.20.10 are still crashing. It happens when closing nomachine nx client window, for example. Should I test and report with 2.20.12 anyway?
Comment 59 Chris Wilson 2012-10-22 18:05:44 UTC
(In reply to comment #58)
> According the changelog there are no changes related to sna in 2.20.11 and
> 2.20.12, but 2.20.10 are still crashing. It happens when closing nomachine
> nx client window, for example. Should I test and report with 2.20.12 anyway?

I mentioned that there was a fix for a potential crash in 2.20.12 which being the only reported at the time I'm optimistic that it is also the one afflicting you.
Comment 60 Armands Liepins 2012-10-22 20:45:58 UTC
(In reply to comment #59)
> I mentioned that there was a fix for a potential crash in 2.20.12 which
> being the only reported at the time I'm optimistic that it is also the one
> afflicting you.

Built 2.20.12 - still the same :( I can try to rebuild with --enable-debug=full, open a new bug and provide more details, but tomorrow.
Comment 61 Jesse Barnes 2012-12-11 19:13:06 UTC
Any update?  Maybe the latest one is fixed after all?
Comment 62 Sitsofe Wheeler 2012-12-13 13:58:03 UTC
It's not fixed in Ubuntu 12.10 (I've just tested):
xserver-xorg-video-intel 2:2.20.9-0ubuntu2
linux-image-3.5.0-17

but in a downstream bug ( https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608/comments/155 ) people mention that using SNA resolves the issue.

Jesse:
What change were you thinking might have fixed this issue?
Comment 63 Jesse Barnes 2012-12-13 16:30:35 UTC
I didn't have a specific change in mind, I guess SNA doesn't work for you though?
Comment 64 Sitsofe Wheeler 2012-12-14 09:45:26 UTC
SNA does work for me (I just hadn't tested it on the previous run).
Comment 65 Chris Wilson 2012-12-14 15:00:48 UTC
To be honest, I had hoped that this would have proven to be the unfenced-BLT bug. The known w/a for UXA is to enable DebugWait, which implies that UXA is not handling its domains correctly.

The most likely candidate is:

diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index 76a3146..40e3b67 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -1379,8 +1379,8 @@ Bool intel_uxa_init(ScreenPtr screen)
        }
 
        /* PutImage */
-       intel->uxa_driver->put_image = intel_uxa_put_image;
-       intel->uxa_driver->get_image = intel_uxa_get_image;
+       //intel->uxa_driver->put_image = intel_uxa_put_image;
+       //intel->uxa_driver->get_image = intel_uxa_get_image;
 
        intel->uxa_driver->prepare_access = intel_uxa_prepare_access;
        intel->uxa_driver->finish_access = intel_uxa_finish_access;
Comment 66 Chris Wilson 2012-12-19 11:11:42 UTC
I've pushed a tree to remove some of the optimisations to see if they are the cause of the corruption:

http://cgit.freedesktop.org/~ickle/xf86-video-intel #glyph-cache-bug

Can you please try this branch to see if does the trick?

Rough guide to testing:

$ git clone git://people.freedesktop.org/~ickle/xf86-video-intel
$ cd xf86-video-intel
$ git checkout origin/glyph-cache-bug
$ ./autogen.sh --prefix=/usr
$ make
$ sudo make install
# restart X
Comment 67 Sitsofe Wheeler 2012-12-19 19:31:33 UTC
Chris:
I'm going to struggle to even test your simple patch. How easy is it to cross compile this on a 64 bit Fedora for a 32 bit Ubuntu with a different xorg?
Comment 68 Chris Wilson 2012-12-19 19:36:08 UTC
Nigh-on impossible unless you have the entire build environment for your target as well (-intel will depend upon the X server ABI as defined in the headers, which of course vary over time).

Don't worry the fix is just to switch to SNA, which will happen soon enough.
Comment 69 Sitsofe Wheeler 2012-12-21 11:50:11 UTC
Ok I've built the intel driver on the git branch (the log mentioned it was version 2.20.16) mentioned and the problem is still there.
Comment 70 Chris Wilson 2012-12-21 12:09:13 UTC
Created attachment 71918 [details] [review]
Flush around glyph updates
Comment 71 Chris Wilson 2012-12-21 12:10:15 UTC
Created attachment 71919 [details] [review]
Flush around glyph updates

Rushed.
Comment 72 Sitsofe Wheeler 2012-12-21 19:18:09 UTC
Created attachment 71944 [details] [review]
Disable glyph cache
Comment 73 Sitsofe Wheeler 2012-12-21 21:36:57 UTC
Created attachment 71949 [details]
Screenshot of patched driver with filled in glyphs

If you look at this screenshot which is using the patch on http://paste.debian.net/218151/ you will see that some blocks have lines through them
Comment 74 Sitsofe Wheeler 2012-12-21 22:36:21 UTC
Created attachment 71953 [details]
Screenshot 2 of patched driver with filled in glyphs

This was taken using the patch on http://paste.debian.net/218164/ but no errors were logged...
Comment 75 Chris Wilson 2013-01-12 20:21:16 UTC
Sitosfe, if you get a chance, please could you try -intel.git (or 2.20.18)? I've implemented stricter throttling, so I am wondering if that worksaround the issue like DebugWait.
Comment 76 Chris Wilson 2013-01-16 18:00:28 UTC
Sitsofe reports that commit 441ef916ae6569c88b3d6abaf7fea4d69be49d76
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jan 10 19:14:21 2013 +0000

    intel: Throttle harder
    
does improve matters, but I'm still at a loss to explain why.
Comment 77 Chris Wilson 2013-01-16 18:02:24 UTC
*** Bug 37782 has been marked as a duplicate of this bug. ***
Comment 78 Chris Wilson 2013-01-16 18:02:38 UTC
*** Bug 49396 has been marked as a duplicate of this bug. ***
Comment 79 Chris Wilson 2013-01-16 18:02:55 UTC
*** Bug 39851 has been marked as a duplicate of this bug. ***
Comment 80 Chris Wilson 2013-01-16 18:03:07 UTC
*** Bug 55881 has been marked as a duplicate of this bug. ***
Comment 81 Paul Menzel 2013-02-02 09:27:52 UTC
(In reply to comment #76)
> Sitsofe reports that commit 441ef916ae6569c88b3d6abaf7fea4d69be49d76
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Thu Jan 10 19:14:21 2013 +0000
> 
>     intel: Throttle harder
>     
> does improve matters, but I'm still at a loss to explain why.

Finally I got some time to test that patch too. I checked out branch `debian-unstable` from the Debian packaging Git repository [1] (based on release 2.19.0)

    commit 8ab872522ae0891b8fb52fbb31db52d581c3efa3
    Author: Julien Cristau <jcristau@debian.org>
    Date:   Sun Sep 16 20:47:05 2012 +0200

        Upload to unstable

and applied the following patch on top of it.

    commit f49c3cacd25ffb78ccfff49b001ba89375044145
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Thu Jan 10 19:14:21 2013 +0000

        intel: Throttle harder

Limited testing shows that the glyph corruption is gone. Unfortunately performance seems to be slower too. That means for example maximizing a window it does not happen instantly and I can see how it is redrawn. So basically the same behavior with `"DebugWait" "true"`, if I remember correctly.


[1] http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-intel.git;a=summary
Comment 82 Chris Wilson 2013-02-02 09:34:32 UTC
(In reply to comment #81)
> and applied the following patch on top of it.
> 
>     commit f49c3cacd25ffb78ccfff49b001ba89375044145
>     Author: Chris Wilson <chris@chris-wilson.co.uk>
>     Date:   Thu Jan 10 19:14:21 2013 +0000
> 
>         intel: Throttle harder
> 
> Limited testing shows that the glyph corruption is gone. Unfortunately
> performance seems to be slower too. That means for example maximizing a
> window it does not happen instantly and I can see how it is redrawn. So
> basically the same behavior with `"DebugWait" "true"`, if I remember
> correctly.

What I realised later was that Sitosfe was hitting the bug in libdrm-intel that was causing it to fallback to swrast. After applying that patch, you also need libdrm-intel-2.4.41 or just http://cgit.freedesktop.org/mesa/drm/commit/?id=fdda97007b1dbf95beb16a0e3510fd36c89e8c33

Paul, can you update libdrm and see if the bug returns?
Comment 83 Paul Menzel 2013-02-02 20:59:44 UTC
(In reply to comment #82)
> (In reply to comment #81)
> > and applied the following patch on top of it.
> > 
> >     commit f49c3cacd25ffb78ccfff49b001ba89375044145
> >     Author: Chris Wilson <chris@chris-wilson.co.uk>
> >     Date:   Thu Jan 10 19:14:21 2013 +0000
> > 
> >         intel: Throttle harder
> > 
> > Limited testing shows that the glyph corruption is gone. Unfortunately
> > performance seems to be slower too. That means for example maximizing a
> > window it does not happen instantly and I can see how it is redrawn. So
> > basically the same behavior with `"DebugWait" "true"`, if I remember
> > correctly.
> 
> What I realised later was that Sitosfe was hitting the bug in libdrm-intel
> that was causing it to fallback to swrast. After applying that patch, you
> also need libdrm-intel-2.4.41 or just
> http://cgit.freedesktop.org/mesa/drm/commit/
> ?id=fdda97007b1dbf95beb16a0e3510fd36c89e8c33
> 
> Paul, can you update libdrm and see if the bug returns?

I applied the commit you mentioned on top of

    libdrm (2.4.40-1~deb7u2) sid; urgency=low

and rebuilt the package. Unfortunately I think there is no difference. The glyph corruption is still gone but it is also still slow, so swrast still might be used.

How can I check, what is used, without `glxinfo` installed? I could not spot anything useful in `/var/log/Xorg.0.log`.
Comment 84 Chris Wilson 2013-02-02 21:30:53 UTC
Basically inspect 'sudo perf top' for pixman functions. There is a slim chance you trigger bug 59711 (as in I have no idea what that is about...) and end up with something in the Xorg.log.
Comment 85 Paul Menzel 2013-02-03 12:09:27 UTC
(In reply to comment #83)
> (In reply to comment #82)
> > (In reply to comment #81)

[…]

> > Paul, can you update libdrm and see if the bug returns?
> 
> I applied the commit you mentioned on top of
> 
>     libdrm (2.4.40-1~deb7u2) sid; urgency=low
> 
> and rebuilt the package. Unfortunately I think there is no difference. The
> glyph corruption is still gone but it is also still slow, so swrast still
> might be used.
> 
> How can I check, what is used, without `glxinfo` installed? I could not spot
> anything useful in `/var/log/Xorg.0.log`.

It looks like swrast is not used.

    OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
    OpenGL version string: 1.4 Mesa 8.0.5

Here is the full output.

$ glxinfo
name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, 
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, 
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_EXT_texture_from_pixmap
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 8.0.5
OpenGL extensions:
    GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture, 
    GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object, 
    GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture, 
    GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters, 
    GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters, 
    GL_EXT_rescale_normal, GL_EXT_separate_specular_color, 
    GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_lod, GL_ARB_multitexture, GL_IBM_multimode_draw_arrays, 
    GL_IBM_texture_mirrored_repeat, GL_3DFX_texture_compression_FXT1, 
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, 
    GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, 
    GL_EXT_secondary_color, GL_EXT_texture_env_add, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, 
    GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent, 
    GL_NV_texgen_reflection, GL_NV_texture_env_combine4, 
    GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp, 
    GL_ARB_texture_compression, GL_EXT_framebuffer_object, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_MESA_window_pos, 
    GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_NV_vertex_program, 
    GL_ARB_depth_texture, GL_ARB_shadow, GL_ARB_texture_env_combine, 
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, 
    GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos, 
    GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_NV_vertex_program1_1, 
    GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers, 
    GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects, 
    GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers, 
    GL_ATI_texture_env_combine3, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, 
    GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_ARB_half_float_pixel, 
    GL_ARB_point_sprite, GL_ARB_shading_language_100, GL_ARB_sync, 
    GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object, 
    GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate, 
    GL_OES_read_format, GL_ARB_pixel_buffer_object, GL_ARB_texture_rectangle, 
    GL_EXT_pixel_buffer_object, GL_EXT_texture_rectangle, 
    GL_ARB_framebuffer_object, GL_EXT_framebuffer_blit, 
    GL_EXT_framebuffer_multisample, GL_EXT_packed_depth_stencil, 
    GL_APPLE_object_purgeable, GL_ARB_vertex_array_object, 
    GL_ATI_separate_stencil, GL_EXT_gpu_program_parameters, GL_OES_EGL_image, 
    GL_ARB_copy_buffer, GL_ARB_map_buffer_range, 
    GL_EXT_separate_shader_objects, GL_ARB_ES2_compatibility, 
    GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, 
    GL_ARB_provoking_vertex, GL_ARB_sampler_objects, GL_EXT_provoking_vertex, 
    GL_ARB_robustness

32 GLX Visuals
    visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
  id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x021 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x022 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x08b 24 tc  0  24  0 r  . .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x08c 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x08d 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x08e 24 tc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x08f 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x090 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x091 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x092 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x093 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x094 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x095 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x096 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8 16 16 16  0  0 0 Slow
0x097 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x098 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x099 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x09a 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x09b 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x09c 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x09d 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x09e 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x09f 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0a0 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0a1 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x0a2 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0a3 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0a4 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x0a5 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8 16 16 16  0  0 0 Slow
0x0a6 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x0a7 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x05a 32 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None

48 GLXFBConfigs:
    visual  x   bf lv rg d st  colorbuffer  sr ax dp st accumbuffer  ms  cav
  id dep cl sp  sz l  ci b ro  r  g  b  a F gb bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------------
0x05b  0 tc  0  16  0 r  . .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x05c  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x05d  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x05e  0 tc  0  16  0 r  . .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x05f  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x060  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x061 24 tc  0  24  0 r  . .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x062 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x063 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x064 24 tc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x065 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x066 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x067 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x068 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x069 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x06a 24 tc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x06b 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x06c 32 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x06d  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x06e  0 tc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x06f 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x070 24 tc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8 16 16 16  0  0 0 Slow
0x071 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x072 24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
0x073  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x074  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x075  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x076  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x077  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x078  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x079 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x07a 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x07b 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  0 0 None
0x07c 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x07d 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x07e 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x07f 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x080 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x081 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0  0  0  0  0  0  0  0 0 None
0x082 24 dc  0  32  0 r  . .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x083 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x084 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x085  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x086  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x087 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  0 0 None
0x088 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8 16 16 16  0  0 0 Slow
0x089 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8  0  0  0  0  0 0 None
0x08a 24 dc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow
Comment 86 Paul Menzel 2013-02-03 12:14:04 UTC
(In reply to comment #84)
> Basically inspect 'sudo perf top' for pixman functions.

Alright.

> There is a slim chance you trigger bug 59711 (as in I have no idea what that
> is about...) and end up with something in the Xorg.log.

Unfortunately with two patches applied, using `xrandr` to enable the external screen seems to lock up the system. I have to find more time to look into this.
Comment 87 Chris Wilson 2013-06-05 22:45:28 UTC
*** Bug 65433 has been marked as a duplicate of this bug. ***
Comment 88 João M. S. Silva 2013-07-23 17:30:02 UTC
I have removed xorg-x11-drv-intel thinking it would fall back to xorg-x11-drv-vesa but it seems to have fallen back to i915 from the kernel. Is this correct?

Anyway, the font corruption issue disappeared.

What is the difference between using the driver from xorg-x11-drv-intel and the one from the kernel?
Comment 89 Chris Wilson 2013-07-23 18:02:15 UTC
(In reply to comment #88)
> I have removed xorg-x11-drv-intel thinking it would fall back to
> xorg-x11-drv-vesa but it seems to have fallen back to i915 from the kernel.
> Is this correct?

No. I guess you are using xorg-x11-drv-modesetting as that is the modern fallback.
 
> Anyway, the font corruption issue disappeared.

The right fix is to enable Option "AccelMethod" "SNA".
Comment 90 linux.testing.marantz 2014-02-10 00:39:22 UTC
Created attachment 93730 [details]
Screenshot 1 of 5, terminal filled with X's, corruption changes after scrot
Comment 91 linux.testing.marantz 2014-02-10 00:41:32 UTC
Created attachment 93731 [details]
Screenshot 1 of 5, terminal filled with X's, corruption changes after scrot
Comment 92 linux.testing.marantz 2014-02-10 00:42:14 UTC
Created attachment 93732 [details]
Screenshot 2 of 5, terminal filled with X's, corruption changes after scrot
Comment 93 linux.testing.marantz 2014-02-10 00:43:33 UTC
Created attachment 93733 [details]
Screenshot 3 of 5, terminal filled with X's, corruption changes after scrot
Comment 94 linux.testing.marantz 2014-02-10 00:44:34 UTC
Created attachment 93734 [details]
Screenshot 4 of 5, terminal filled with X's, corruption changes after scrot
Comment 95 linux.testing.marantz 2014-02-10 00:45:17 UTC
Created attachment 93735 [details]
Screenshot 5 of 5, terminal filled with X's, corruption changes after scrot
Comment 96 linux.testing.marantz 2014-02-10 00:49:39 UTC
Created attachment 93736 [details]
Log files dmesg + Xorg,0,log showing machine info for screenshots above
Comment 97 Sitsofe Wheeler 2014-02-10 06:52:05 UTC
Screenshots and logs for linux.testing.marantz@gmail.com are on a system running
Kernel 3.11.0-12-generic #19-Ubuntu
xorg-intel 2:2.99.904-0ubuntu2
SNA is on: intel(0): SNA initialized with Eaglelake (gen4.5) backend
Chipset is a Q45/Q43.

linux.testing.marantz:
I've add you to the CC list of this bug report so you will see a reply. It is a good practice to do this otherwise you will miss followups...

It is unlikely that the bug you are seeing is the one filed here as your chipset is not an i915 series and you are using SNA on a recent kernel+xorg. I would strongly urge you to open new bug, attach one of your screenshots, your xorg and dmesg logs and then report the versions of your kernel, xorg and xorg intel along with steps on how to reproduce the issue in a comment.
Comment 98 Sitsofe Wheeler 2015-02-12 16:15:28 UTC
I don't see this in Ubuntu 14.04 as it uses SNA and UXA is going to die so I think we can finally close this.
Comment 99 Peter Nowee 2015-04-08 15:24:02 UTC
I ran into this bug on a fresh install of Debian 8 (Jessie) RC2 on an EeePC 701 4G with Intel i915GM graphics. Linux kernel 3.16, X.Org 1.16.4, X.Org intel module 2.21.15.

Using SNA instead of UXA, as suggested above, seems to still solve it:

# cat /etc/X11/xorg.conf 
Section "Device"
        Identifier "Intel Graphics"
        Driver "intel"
        Option "AccelMethod" "sna"
EndSection


I see that Debian is preparing to move to SNA [1]:

> xserver-xorg-video-intel (2:2.99.911+git20140529-1~exp2) experimental; urgency=medium
> ..
> * Stop overriding default upstream acceleration method (i.e. default to SNA
>    instead of UXA).
>
> -- Vincent Cheng <vcheng@debian.org>  Mon, 02 Jun 2014 23:47:23 -0700

However, that change is still in Debian's "experimental" area, not in the upcoming stable (Jessie) release.

(Links to corresponding Debian bug reports in Paul's comment 44 above.)

[1] http://metadata.ftp-master.debian.org/changelogs//main/x/xserver-xorg-video-intel/experimental_changelog