Created attachment 25152 [details] Corrupted layout Section "Device" Identifier "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller" Driver "intel" BusID "PCI:0:2:0" Option "AccelMethod" "UXA" EndSection rahul@googly ~ $ uname -a Linux googly 2.6.30-rc2-zen0-08372-gb1961bf-dirty #7 SMP PREEMPT Sun Apr 26 16:17:05 CEST 2009 i686 Genuine Intel(R) CPU T2300 @ 1.66GHz GenuineIntel GNU/Linux Kernel uses this patch http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff_plain;h=f544847fbaf099278343f875987a983f2b913134;hp=cd97824994042b809493807ea644ba26c0c23290 For corruption, see the attached image.
Please attach Xorg log according to http://intellinuxgraphics.org/how_to_report_bug.html. Does this ever work for you in a previous version? Does removing UXA from xorg.conf work?
Works with 2.6.99.902 and UXA - that is what I am using right now. Will compile 2.7 again tomorrow and then attach the Xorg log, will also try to remove UXA and see what happens. Funny thing is that this corrupted layout occurs after running the server for some time - say half an hour. Then it starts getting corrupted. Will report more details tomorrow.
I can confirm this bug, my i915gm produces the same symptoms when x is running for several hours (attaching an external VGA seems to shorten the time before the corruption shows up). I use kms/dri2/uxa with kernel 2.6.30-rc3, xserver-1.6.1, mesa-7.4, xf86-video-intel 2.7 branch (commit 296a986e5258e2fd13ec494071b7063bd639cd68).
Created attachment 25232 [details] Xorg log - Intel 2.7.0 - corrupted layput
My gm945 does the same, especially after suspend to disk I see glyph and pixmap corruptions all over the place.
Same for me (gma950) I've noticed that corruption only happens when system begins to use swap. With swap disabled I have no corruption.
Bug is reproducible even with tiling disabled. xf86-video-intel from git, commit 8255cca2c9092f7ecb798944aa8f03fa3efcfa6c kernel 2.6.30-rc3-git7, xorg-server-1.6.1 Can't test it with EXA, because driver supports UXA only.
Ok, so corruption happens only when swap is enabled, so I suspect it's caused by bit_17 not restored (or restored incorrectly) after paging operations. Question to the driver developers: What will happen if pages allocated by drm_calloc, i915_gem.c:2018, and swizzled only right after allocation, will be swapped out, and then loaded into memory where bit 17 differs?
Created attachment 25551 [details] [review] patch to disable bo reuse As stated in http://bugs.freedesktop.org/show_bug.cgi?id=16835#c18 cause of this bug is BO reuse, and disabling BO reuse seems to help. Here's a patch that can be used as a temporary workaround
Hm, it seems that disabling bo reuse doesn't solve the problem. Or my patch doesn't disable bo reuse. With patch corruption shows up later. Without patch after running intel-gpu-tools tests corruption shows up immediately, with patch it doesn't, but it does later. :(
My IBM Thinkpad R31 with i830 with Ubuntu Jaunty gets corrupted fonts in a few minutes especially with Firefox. The Intel driver is 2.7.0 I think (I'm on a different pc now). It's got 512 mb memory so I'm not sure how it will do with no swap but I'll try it tomorrow. Jerry
Just tried turning swap off. The Thinkpad R31 i830 has 512 mb memory so it is not very happy with swapoff. The font corruption still appears, however it is slower to spread from character to character. Do note Ubuntu Jaunty is strongly affected, with driver 2.7.0 and the preceding drivers. Ubuntu Intrepid is not affected that I've noticed. I have an IBM ThinkCentre A30 with Intel i845. It does not have the problem (yet). Jerry
Vasily: bit 17 shouldn't be related, because none of the pixmaps in question are tiled, and that's the only time the CPU and GPU disagree on handling things.
(In reply to comment #13) > Vasily: bit 17 shouldn't be related, because none of the pixmaps in question > are tiled, and that's the only time the CPU and GPU disagree on handling > things. > Eric, I don't know what causes this bug, I'm not a gpu-expert, so I'm trying to guess. Anyway, don't hesitate to ask me for more info/logs if you need any.
Option "Tiling" "false" still smears fonts on my i830 video on the Thinkpad R31 which is running Ubuntu jaunty, with Option "AccelMethod" "uxa" (not sure if there is any other option with the current driver). Perhaps the preceding comments are referring to a different type of tiling? Jerry
2 xf86-video-intel developers: Out of curiosity, when this annoying bug will be fixed? It makes gma950 totally unusable, and I'm wondering why priority of this bug is not highest. Btw, one more ubuntu release (i.e. 9.10) with buggy intel driver and you'll lose 95% of linux users with intel graphics. http://www.phoronix.com/scan.php?page=news_item&px=NzIyMA
This is now more annoying than the infamous KDE bug "system tray background are not transparent". While that was a minor UI regression, this is clearly more than that. I have to restart my X session after every couple of hours or so going through the trouble of saving all the work that I doing and then resuming it again. At this point, I only wish I knew how to fix it so that I could lend a helping hand. Sadly, my knowledge in this field is rather limited to say the least.
2.7.1 still produces this bug, so I'm stuck with 2.6.3. Do someone have any idea what causes this?
i830 video graphics as of May 23 with all latest Ubuntu 9.04 updates & xorg 2.27.1-1 fonts get corrupted and smear within a few minutes. gtkperf and firefox aggravate the situation. Turning swap off does not help. i830 on the IBM Thinkpad R31 runs just fine with Ubuntu intrepid 8.10 which is the only way I can get work out of that pc. Dual boot saves the day. i845 video graphics on IBM ThinkCentre tower does not have the problem. It was running quite slowly however with latest updates it's reasonable. I'm running Ubuntu jaunty 9.04 and Ubuntu karmic 9.10 alpha O.K. Jerry
today I upgraded to .30-rc7 + libdrm-2.4.11 and the problem seems to be fixed, at least there is no corruption after 6 hours of uptime.
Corruption persists with libdrm-2.4.11 and 2.6.20-rc7 (my screen is corrpupted atm). Will rebuild major X components and see if that improves anything.
Corruption persists for me, too, with -rc7 kernel and drm, mesa, xserver, xf86-video-intel git master as of a couple of days ago. Corruption appeared after just one resume from suspend to disk.
(In reply to comment #20) > today I upgraded to .30-rc7 + libdrm-2.4.11 and the problem seems to be fixed, > at least there is no corruption after 6 hours of uptime. > It's still reproducible for me with 2.6.30-rc7, libdrm from git, xf86-video-intel from git. If you don't want to wait for a couple of hours, just run tests from intel-gpu-tools to get fonts and some pixmaps corrupted.
i am also having this problem. i am running ubuntu karmic alpha 1 with: xserver-xorg-video-intel 2:2.7.1-1ubuntu1 xorg 1:7.4~5ubuntu20. intel 915. i'm new to linux and reporting bugs, so if there is any more info i can provide, please ask.
Created attachment 26205 [details] example of font and graphics corruption
Ubuntu 9.10 Karmic Koala Alpha 1 has the same font smear/graphics character corruption with Intel i830 video graphics on IBM Thinkpad R31. That's installed from the same Ubuntu Karmic Koala install CD that works O.K. as far as fonts go on three other PC's, with Intel i845, ATI Radeon Express, ATI Mobility. Ubuntu 9.04 Jaunty Jackalope smears fonts, Ubuntu 8.10 Intrepid Ibex does not. Jerry
It seems that this patch: http://lists.freedesktop.org/archives/intel-gfx/2009-May/002566.html fixes the problem.
Rahul: Does the following patch queued up to for-linus in the kernel help you? commit 07f4f3e8a24138ca2f3650723d670df25687cd05 Author: Kristian Høgsberg <krh@redhat.com> Date: Wed May 27 14:37:28 2009 -0400 i915: Set object to gtt domain when faulting it back in When a GEM object is evicted from the GTT we set it to the CPU domain, as it might get swapped in and out or ever mmapped regularly. If the object is mmapped through the GTT it can still get evicted in this way by other objects requiring GTT space. When the GTT mapping is touched again we fault it back into the GTT, but fail to set it back to the GTT domain. This means we fail to flush any cached CPU writes to the pages backing the object which will then happen "eventually", typically after we write to the page through the uncached GTT mapping. [anholt: Note that userland does do a set_domain(GTT, GTT) when starting to access the GTT mapping. That covers getting the existing mapping of the object synchronized if it's bound to the GTT. But set_domain(GTT, GTT) doesn't do anything if the object is currently unbound. This fix covers the transition to being bound for GTT mapping.] Fixes glyph and other pixmap corruption during swapping. fd.o bug #21790 Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> Vytautas: Does the following patch queued up to for-linus in the kernel help you? commit 07f4f3e8a24138ca2f3650723d670df25687cd05 Author: Kristian Høgsberg <krh@redhat.com> Date: Wed May 27 14:37:28 2009 -0400 i915: Set object to gtt domain when faulting it back in When a GEM object is evicted from the GTT we set it to the CPU domain, as it might get swapped in and out or ever mmapped regularly. If the object is mmapped through the GTT it can still get evicted in this way by other objects requiring GTT space. When the GTT mapping is touched again we fault it back into the GTT, but fail to set it back to the GTT domain. This means we fail to flush any cached CPU writes to the pages backing the object which will then happen "eventually", typically after we write to the page through the uncached GTT mapping. [anholt: Note that userland does do a set_domain(GTT, GTT) when starting to access the GTT mapping. That covers getting the existing mapping of the object synchronized if it's bound to the GTT. But set_domain(GTT, GTT) doesn't do anything if the object is currently unbound. This fix covers the transition to being bound for GTT mapping.] Fixes glyph and other pixmap corruption during swapping. fd.o bug #21790 Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> (swapping isn't the only case that this bug can fix, but it's the most common as the cpu cache of the object will be hot with writes at the time we don't want it)
Not that I know anything about patches, however the referenced patch looks like it is for i915 while I have the problem with an i830. Thanks, Jerry
Jerry, even 8xx intel cards use i915.ko module. i830.ko is used only by old XFree86 4.3 and/or Xorg 6.7. Newer Xorg uses i915.ko
Jerry, you have different hardware and should be on your own bug report, not tagging along on someone else's.
(In reply to comment #28) > Rahul: Does the following patch queued up to for-linus in the kernel help you? > Hi Eric, Thanks for the patch. I just recompiled my kernel with the patch and would report if I see any problems. I am trying to mess around with intel-gpu-tools to see if I can reproduce the corruption. Thanks Rahul
It really looks like that this annoying bug has been fixed for me (GM965, DRI2+KMS) thanks to this patch. Congratulations to Eric and Kristian!
Latest Intel xorg driver 2.7.99 on i845 video graphics gets character smear/extra pixels as well as i830. I now have 2 pc's, a Thinkpad R31 with i830, and a ThinkCentre tower with i845 which are not usuable with Ubuntu karmic 9.10 for any length of time. Jerry
The patch provided by Eric (for the kernel) fixes this bug for me. Should I mark this bug as fixed?
Thanks everyone for the reports and testing and feedback! It seems evident that the central issue here is fixed. If you still have lingering side issues, please feel free to open new bug reports for them. -Carl
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.