Bug 26002

Are you not going to mention a few pertinent details, such as chipset, a dmesg, Xorg.log or driver versions, but just link to circumstantial evidence?

Created attachment 42142 [details]
Xorg log

I'm sorry, this wasn't a very good bug report was it?  I have attached my Xorg log, dmesg output and lshw output.  I'm not sure what the official chipset is, but I'm sure the graphics are "Mobile 915GM".

I have reproduced this bug using the following kernels: 2.6.35 (Ubuntu Maverick generic kernel) and 2.6.37-rc8.
I have reproduced this bug using the following xserver-xorg-video-intel driver versions: 2.12.0 (current Ubuntu Maverick version) and 2.13.901 (from ppa:ubuntu-x-swat/x-updates).

Please let me know if you need any more information.

Created attachment 42152 [details]
dmesg output

Created attachment 42162 [details]
lshw output

Does 2.6.36 work correctly?

Depends, I've very similar reports from 2.6.33. One of the most important assessments would be whether it is glyph data that existed before the suspend that is corrupted or whether it is glyph data that we attempted to upload afterwards. The later could be explained by a clflush issue that became critical in -next (but I couldn't see any reason why the current kernels did not also suffer from the same bug, just without any valid reason to push the patch to -fixes).

To answer your question, Rafael: kernel 2.6.36 has the same problem.

I think I have experienced the same problem, but it is not limited to 2.6.36, the problem is visible in 2.6.32, too. I have reported this bug in the Debian BTS here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613317


There are screenshots, dmesg and xorg logs there.

dmesg: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=44;filename=dmesg.txt;att=1;bug=613317

xorg.log: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=44;filename=Xorg.0.log;att=2;bug=613317


The graphics card is also an Intel card and there are also background image corruptions which manifest on vanilla 2.6.37+git35d34df7.

I have just observed that gitk's fonts and xterm's fixed fonts were not affected. I hope this info is useful.

Is this the same bug as bug #27572?

Bug #27572 seems to be related to a different type of corruption.  The bug reported here only mentions corrupted font glyphs.  However, there may be a similar cause to both this bug and #27572--some kind of memory corruption?

This bug is still present in Ubuntu Natty (running Xubuntu 32-bit).
Kernel: 2.6.38-8-generic
Intel driver: 2:2.14.0-4ubuntu7.1

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
OS: Xubuntu 11.04 i386

See https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745608

See screenshots at #16 - #19 taken on the 945G

I have 3 different machines (different intel video chipset), one of which suffers badly from this bug.

Summery:

eeepc 900: sometimes the broken fonts and other anomalies occur, restarting X seems to make them go away.
Chip set: VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)

asus mother board 1: always broken fonts, switching to different fonts or sizes can make the screen readable again.
Chip set: VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)

asus mother board2: no problems do far.
Chip set: VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)

All 3 systems running same Natty Kubuntu (kernel 2.38-8.42), 915GM and 82G33 in i386, 82945G in amd64.

Ferry

Sitsofe Wheeler gave me the advise to try putting the following in my xorg.conf:

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

As there was no xorg.conf I created one with only the lines above (rest auto detected).

The font corruption is now disappeared.

I have no clue why and if we should now close this bug.

But this seems to be a good workaround.

Ferry

Ok, 3.4-rc2 has fixes for all known tiling issues and regressions (which this one is likely yet another case of) for gen3 (i.e. i915, i945, g33, pnv). Please test with that kernel and check whether you're still seeing these corruptions.

More precisely

commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Mar 21 10:48:18 2012 +0000

    drm/i915: Mark untiled BLT commands as fenced on gen2/3

and

commit c9c4b6f6c28354f1df9bd288dc33ba7ae0e66aaa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Dec 14 13:57:15 2011 +0100

    drm/i915: fix swizzle detection for gen3

I'll close this issue as fixed, please reopen if you still see corruptions on kernels with these 2 patches applied.

(In reply to comment #16)
> More precisely
> 
> commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Mar 21 10:48:18 2012 +0000
> 
>     drm/i915: Mark untiled BLT commands as fenced on gen2/3
> 
> and
> 
> commit c9c4b6f6c28354f1df9bd288dc33ba7ae0e66aaa
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Dec 14 13:57:15 2011 +0100
> 
>     drm/i915: fix swizzle detection for gen3
> 
> I'll close this issue as fixed, please reopen if you still see corruptions on
> kernels with these 2 patches applied.

I'll compile and try this. I am running Debian's 3.2.0 kernel and still experience this kind of corruption after some hibernate/resume cycles.

Meanwhile I realised gitk and xterm were not affected because they used other fonts than the rest of the applications and only the fonts used at the time of the hibernate were the ones affected.

I'll come back (probably Sunday) for feedback.

(In reply to comment #16)
> More precisely
> 
> commit 7dd4906586274f3945f2aeaaa5a33b451c3b4bba
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Wed Mar 21 10:48:18 2012 +0000
> 
>     drm/i915: Mark untiled BLT commands as fenced on gen2/3
> 
> and
> 
> commit c9c4b6f6c28354f1df9bd288dc33ba7ae0e66aaa
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Dec 14 13:57:15 2011 +0100
> 
>     drm/i915: fix swizzle detection for gen3
> 
> I'll close this issue as fixed, please reopen if you still see corruptions on
> kernels with these 2 patches applied.

Unfortunately the bug it still present on my system.

Created attachment 73032 [details]
Font corruption on linux 3.4.0-rc3

As you can see, I still got font corruption after a hibernate-sleep cycle with linux 3.4.0-rc3.

I am unable to reopen the bug since, it seems, I don't have the necessary rights. So, please, somebody with the necessary rights, reopen the bug.

How similar is this to https://bugs.freedesktop.org/show_bug.cgi?id=36326 ?

Ok, we need to run a few tests: Can you please grab the intel-gpu-tools suite from git git://anongit.freedesktop.org/xorg/app/intel-gpu-tools and run the kernel test-suite with

# make test

You need to be root and no other drm client like X may be running. Please attach the output of the complete test-run (and yes, it takes a while).

(In reply to comment #21)
> How similar is this to https://bugs.freedesktop.org/show_bug.cgi?id=36326 ?

I am sorry in advance if I didn't understood the proper meaning of your question, but it doesn't look similar to that. It seems that the bug 36326 manifests as certain glyph line deletion, while in my case loos like glyph scrambling. Please be more specific, if I didn't understand what your line of questioning.

I guess the intel-gpu-tools suite will bring up more info.

Created attachment 73046 [details]
string.printable output

Here is a string.printable output on my machine.

(In reply to comment #23)
> (In reply to comment #21)
> > How similar is this to https://bugs.freedesktop.org/show_bug.cgi?id=36326 ?
> 
> I am sorry in advance if I didn't understood the proper meaning of your
> question, but it doesn't look similar to that. It seems that the bug 36326
> manifests as certain glyph line deletion, while in my case loos like glyph
> scrambling.

That's precisely what I was trying to verify, thank you. From your description of this being swap triggered (or hibernate) in this case it is likely to be swizzling at fault. If you had seen a pattern like 36326, that would just be corruption whilst uploading or somesuch (and so likely to have been another bug like drm/i915: Mark untiled BLT commands as fenced on gen2/3).

Meh, I've just noticed that Eddy has a i965GM whereas the original reporter has a i915GM. The i965GM issue likely L-shaped bit17 swizzling woes, and should be easily detectable by tiled_swapping failing in i-g-t.

The i915gm issues should be solve, Christian, please reopen if this is not the case.

Eddy, please attach the output of the intel-gpu-tools testsuite so I can tell you whether this is a known issue.

Everyone else: If you still have issues with v3.4-rc series, please open new bug reports - if you have corruptions but not exactly matching hw there's a really big chance that you have a different bug.

Created attachment 73056 [details]
intel-gpu-tools make test output

Here is the output of 'make test' on 3.4.0-rc3.

Interestingly enough 'make test' on the Debian 3.2.0 kernel lead to lots of failed tests, a kernel oops and, obviosly failed to finish, while 3.4.0-rc3 looks a lot more stable, although there were some failures.

BTW, pointing out the configuration options that enabled the right debugfs interface would have been useful, it took me 4 kernel recompilations and some manual tinkering of the .config after seeing the official Debian kernel 3.2.0 has the proper dri interface on debugfs.

(In reply to comment #26)
> Meh, I've just noticed that Eddy has a i965GM whereas the original reporter
> has
> a i915GM. The i965GM issue likely L-shaped bit17 swizzling woes, and should
> be
> easily detectable by tiled_swapping failing in i-g-t.
> 
> The i915gm issues should be solve, Christian, please reopen if this is not
> the
> case.
> 
> Eddy, please attach the output of the intel-gpu-tools testsuite so I can tell
> you whether this is a known issue.
> 
> Everyone else: If you still have issues with v3.4-rc series, please open new
> bug reports - if you have corruptions but not exactly matching hw there's a
> really big chance that you have a different bug.

Any news? I already posted the output of make test a few days ago and it looks to me like you were right on your suspicion. Is so, what's next?

I am still experiencing this bug on Kubuntu Precise and am reopening the bug per comment #26.  I am using xserver-xorg-video-intel version 2:2.19.0-0ubuntu1~xup1 from the X Updates PPA (https://launchpad.net/~ubuntu-x-swat/+archive/x-updates) and can still reproduce the glyph corruption using the following i386 kernels:
 . 3.4.0-030400rc5-generic from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc5-precise/
 . 3.4.0-994-generic from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/2012-05-03-precise/

Anything else I should try?  Xorg-edgers perhaps?

** Current System Info **
OS: Kubuntu 12.04 i386 w/ KDE SC 4.8.2
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1.5GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
Linux Kernel: 3.2.0-24-generic
Screen Resolution: 1280 x 768

Okay, so I bit the bullet and updated X and the intel driver using the following PPAs:
 . xorg-edgers (https://launchpad.net/~xorg-edgers/+archive/ppa)
 . intel-sna branch (https://launchpad.net/~sarvatt/+archive/intel-sna)

I also used the 3.4.0-030400rc5-generic kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc5-precise/

I'm not sure if the intel-sna branch or kernel update was necessary, but I have not been able to reproduce this bug since updating.  The updated X + driver did cause other issues for me, though, particularly with OpenGL apps, just as a warning to anyone else wishing to try this driver.  Closing again as fixed.

(In reply to comment #30)
> The updated X + driver did
> cause other issues for me, though, particularly with OpenGL apps, just as a
> warning to anyone else wishing to try this driver.

A warning is not much help for me to fix them... Can you please file a bug on bugzilla.freedesktop.org and attach your Xorg.0.log?

Here you go :)
https://bugs.freedesktop.org/show_bug.cgi?id=49442

While testing for other bugs, I discovered that this driver exhibits the font corruption bug:
2:2.19.0+git20120501.7e09babb-0ubuntu0sarvatt~precise (from xorg-edgers PPA)
...and this one doesn't:
2:2.19.0+git20120501.7e09babb-0ubuntu0sarvatt2~sna~precise (from intel-sna PPA)

Same version, but the second driver uses SNA (Sandy Bridge New Acceleration).  Is SNA going to eventually become the default acceleration in the Intel driver?  Will this be enabled on all i915GM hardware?  If not, then should this bug be reopened?