Rendering problems on edgy with Intel Integrated Graphics Device

[Mary Gardiner]

Every few times that I resume from suspend or hibernate, I see severe rendering glitches. A few screenshots will be attached.

Here's the lspci output for my graphics card:

00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

[Mary Gardiner (puzzlement)]

Further comments: the only fix I've found is a reboot (restarting gdm is not sufficient, I tend to get left with an all-black login screen save for the input box). And non-GTK applications are affected: xterms do not render at all.

[Soren Hansen (soren)]

I'm experiencing this issue as well. It happens once every 5-10 times.

I've reassigned this bug to the i810 X driver for now, but I suspect it might be a kernel issue since restarting X has no effect.

A few minutes ago I discovered that doing a few suspend/resumes actually fixes it again, which is also quite interesting.

[Chris Jones (cmsj)]

This morning I resumed my Thinkpad X40 and the screen was quite corrupted, all
applications were failing to draw correctly and I had to reboot to fix it.

[Chris Jones (cmsj)]

Created an attachment (id=7348)
Screenshot showing corruption

[Chris Jones (cmsj)]

see https://launchpad.net/distros/ubuntu/+source/xserver-xorg-video-i810/+bug/60882

[Alanh-fairlite (alanh-fairlite)]

If you are using vbetool in your suspend/resume scripts. Disable it.

[Chris Jones (cmsj)]

I am seeing this also on my Thinkpad X40 with:

00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

[Chris Jones (cmsj)]

Upstream suggests removing vbetool from resume scripts

[Soren Hansen (soren)]

That actually seems to have solved it for me. And not just that: Sometimes the display wouldn't even come back at all, but I suspected that was a different issue, but this also seems to be solved.

I've just done 10-12 suspend/resume cycles and everything works like a charm. I don't think I've ever been able to do that in Edgy.

Now we just have to figure out which laptops to do this for..

[Paul Sladen (sladen)]

Chris, vbetool tool and state restoring on resume are controlled by:

  SAVE_VBE_STATE=true
  POST_VIDEO=true

in /etc/default/acpi-support

Can you try toggling those?

[Soren Hansen (soren)]

I only set SAVE_VBE_STATE to false. That did the trick for me.

[Chris Jones (cmsj)]

as with Soren, setting SAVE_VBE_STATE to false appears to have solved this. I just did five consecutive suspend/resumes at least and the system appears to be functioning as expected.

In terms of which laptops, as I mentioned above, this is an IBM Thinkpad X40, type 2372. Additional info available on request.

[Chris Jones (cmsj)]

Thanks, that does seem to have done the trick.

[Alanh-fairlite (alanh-fairlite)]

O.k. closing. vbetool does seem to introduce problems.

[Mary Gardiner (puzzlement)]

In my case, sadly, setting SAVE_VBE_STATE=false (no other changes to the default) causes terrible rendering failure on about half of all resumes: the screen goes black-green and spotty (it's not quite like just being black and backlit). I need to reboot/reset to fix it.

I will try toggling POST_VIDEO too.

[Paul Sladen (sladen)]

Soren, Chris, Mary: Please can you all supply the following information so we know what your particular laptops are, and can match up any workarounds already in-place:

  grep . /var/lib/acpi-support/*-*

[Soren Hansen (soren)]

On Fri, Oct 13, 2006 at 12:05:51PM -0000, Paul Sladen wrote:
> Soren, Chris, Mary: Please can you all supply the following information
> so we know what your particular laptops are, and can match up any
> workarounds already in-place:

Good idea.

> grep . /var/lib/acpi-support/*-*

/var/lib/acpi-support/bios-version:1UETB6WW (1.66 )
/var/lib/acpi-support/system-manufacturer:IBM
/var/lib/acpi-support/system-product-name:23716EG
/var/lib/acpi-support/system-version:ThinkPad X40

Also, the PCI ID of my graphics card:

$ lspci -n -s `lspci|grep VGA\ compatible|cut -f1 -d\ ` \ |cut -f3 -d' '
8086:3582

[Chris Jones (cmsj)]

-(cmsj@waishou)-(~)- grep . /var/lib/acpi-support/*-*
/var/lib/acpi-support/bios-version:1UETD1WW (2.06 )
/var/lib/acpi-support/system-manufacturer:IBM
/var/lib/acpi-support/system-product-name:2372Y17
/var/lib/acpi-support/system-version:ThinkPad X40

pci id of the graphics chip:

00:02.0 0300: 8086:3582 (rev 02)

[Mary Gardiner (puzzlement)]

> I will try toggling POST_VIDEO too.

SAVE_VBE_STATE=false
POST_VIDEO=false

doesn't give me video back at all.

[Mary Gardiner (puzzlement)]

$ grep . /var/lib/acpi-support/*-*
/var/lib/acpi-support/bios-version:Version 1.04
/var/lib/acpi-support/system-manufacturer:FUJITSU
/var/lib/acpi-support/system-product-name:LifeBook S Series

[Mary Gardiner (puzzlement)]

I haven't personally seen this bug for a long time, possibly since before Edgy's release. It doesn't seem to be *intentionally* fixed, but it might be fixed nonetheless. Anyone else still have it?

[Timo Aaltonen (tjaalton)]

closing the bug since it seems to have been fixed by something.

[Bruce van der Kooij (brucevdk)]

I recently upgraded to Ubuntu 8.04 and apparently ran into this bug. I never encountered these problems before in previous releases, I was previously running 7.10 (Gutsy). Toggling SAVE_VBE_STATE to false in /etc/default/acpi-support as Paul Sladen explained in Comment #8 solved the rendering problems for me.

Here's the output for grep . /var/lib/acpi-support/*-*:

/var/lib/acpi-support/bios-version:1VET71WW (1.29 )
/var/lib/acpi-support/system-manufacturer:IBM
/var/lib/acpi-support/system-product-name:2887AVG
/var/lib/acpi-support/system-version:ThinkPad R51

And lspci | grep -i graphics:

00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)