|
Description
Sitsofe Wheeler
2011-04-17 07:06:25 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...
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). For 915GM it is important to test with 2.15.0 as well to rule out one source of tiling corruption. 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)... Thanks Sitsofe. I can now cry myself to sleep. 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 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. (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. 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... 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. 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. The symptoms described in this bug are very similar to those described in the closed bug #34662 ... 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 . 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. 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. 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... 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. 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. 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.
Closing our bug https://bugzilla.redhat.com/708849 against this one. 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. 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! Created attachment 47554 [details]
Xorg log taken after crash
Mainline xf86-video-intel.git still blows up.
Created attachment 47555 [details]
i915_error_state after crash
Created attachment 47556 [details] [review] Use pot size, not multiple-of-two tile height Created attachment 47558 [details]
i915_error_state for 3.0.0-rc1 (without pot patch)
Created attachment 47559 [details]
i915_error_state for 3.0.0-rc1 (with pot patch)
Created attachment 47560 [details] [review] Fix unfenced alignment on pre-g33 Created attachment 47561 [details]
915_error_state after fix unfenced alignment on pre-g33 patch
Created attachment 47563 [details]
915_error_state after Y-tiling DDX patch
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. 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... 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. :) 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... There is a rumour going round that this is actually Bug #28798 . I haven't had a chance to confirm or deny this... 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 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.
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. 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? 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. 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. Reportedly still happening in Ubuntu Precise: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608 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. 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 In the Red Hat Bugzilla this issue is reported as #704959 [1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=704959 (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. There are also some reports suggesting this happens with 945GM/GMS too. Could the bug title be updated please to reflect that please? 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.
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 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. (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`. (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 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.
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). 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. (In reply to comment #55) > With sna accel X crashes occasionally. Tell me more. New bug, and make sure you have 2.20.12. (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. 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? (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. (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. Any update? Maybe the latest one is fixed after all? 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? I didn't have a specific change in mind, I guess SNA doesn't work for you though? SNA does work for me (I just hadn't tested it on the previous run). 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;
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 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? 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. 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. Created attachment 71918 [details] [review] Flush around glyph updates Created attachment 71919 [details] [review] Flush around glyph updates Rushed. Created attachment 71944 [details] [review] Disable glyph cache 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 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... 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. 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. *** Bug 37782 has been marked as a duplicate of this bug. *** *** Bug 49396 has been marked as a duplicate of this bug. *** *** Bug 39851 has been marked as a duplicate of this bug. *** *** Bug 55881 has been marked as a duplicate of this bug. *** (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 (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? (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`. 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. (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 (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. *** Bug 65433 has been marked as a duplicate of this bug. *** 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? (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". Created attachment 93730 [details]
Screenshot 1 of 5, terminal filled with X's, corruption changes after scrot
Created attachment 93731 [details]
Screenshot 1 of 5, terminal filled with X's, corruption changes after scrot
Created attachment 93732 [details]
Screenshot 2 of 5, terminal filled with X's, corruption changes after scrot
Created attachment 93733 [details]
Screenshot 3 of 5, terminal filled with X's, corruption changes after scrot
Created attachment 93734 [details]
Screenshot 4 of 5, terminal filled with X's, corruption changes after scrot
Created attachment 93735 [details]
Screenshot 5 of 5, terminal filled with X's, corruption changes after scrot
Created attachment 93736 [details]
Log files dmesg + Xorg,0,log showing machine info for screenshots above
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. 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. 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
|
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.