[i945gme] [Hardy] 3D Graphic stop working after resume and resolution change

[Torsten Spindler]

Binary package hint: xserver-xorg-video-intel

This bug can be reproduced the following way:

1) xrandr --size 800x600
2) sudo pm-hibernate
3) resume
4) xrandr --size 1024x600

The 3D graphics disappear and a white frame is shown, with 2D graphics continuing to work. After switching to virtual console and back the 3D graphics are restored.

lspci output on the graphics hardware:

lspci -nn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
lspci -nn: 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)

lspci -vnn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller])
lspci -vnn: Subsystem: Toshiba America Info Systems Unknown device [1179:ff1e]
lspci -vnn: Flags: bus master, fast devsel, latency 0, IRQ 23
lspci -vnn: Memory at 54280000 (32-bit, non-prefetchable) [size=512K]
lspci -vnn: I/O ports at 40f0 [size=8]
lspci -vnn: Memory at 40000000 (32-bit, prefetchable) [size=256M]
lspci -vnn: Memory at 54300000 (32-bit, non-prefetchable) [size=256K]
lspci -vnn: Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
lspci -vnn: Capabilities: [d0] Power Management version 2
lspci -vnn:
lspci -vnn: 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
lspci -vnn: Subsystem: Toshiba America Info Systems Unknown device [1179:ff1e]
lspci -vnn: Flags: bus master, fast devsel, latency 0
lspci -vnn: Memory at 54200000 (32-bit, non-prefetchable) [size=512K]
lspci -vnn: Capabilities: [d0] Power Management version 2

[Torsten Spindler (tspindler)]

Binary package hint: xserver-xorg-video-intel

This bug can be reproduced the following way:

1) xrandr --size 800x600
2) sudo pm-hibernate
3) resume
4) xrandr --size 1024x600

The 3D graphics disappear and a white frame is shown, with 2D graphics continuing to work. After switching to virtual console and back the 3D graphics are restored.

lspci output on the graphics hardware:

lspci -nn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
lspci -nn: 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)

lspci -vnn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA controller])
lspci -vnn: Subsystem: Toshiba America Info Systems Unknown device [1179:ff1e]
lspci -vnn: Flags: bus master, fast devsel, latency 0, IRQ 23
lspci -vnn: Memory at 54280000 (32-bit, non-prefetchable) [size=512K]
lspci -vnn: I/O ports at 40f0 [size=8]
lspci -vnn: Memory at 40000000 (32-bit, prefetchable) [size=256M]
lspci -vnn: Memory at 54300000 (32-bit, non-prefetchable) [size=256K]
lspci -vnn: Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
lspci -vnn: Capabilities: [d0] Power Management version 2
lspci -vnn:
lspci -vnn: 00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
lspci -vnn: Subsystem: Toshiba America Info Systems Unknown device [1179:ff1e]
lspci -vnn: Flags: bus master, fast devsel, latency 0
lspci -vnn: Memory at 54200000 (32-bit, non-prefetchable) [size=512K]
lspci -vnn: Capabilities: [d0] Power Management version 2

[Bryce Harrington (bryce)]

Are you able to reproduce this on an Intrepid LiveCD? If the issue is absent on Intrepid, then perhaps there is a patch we can pull.

[Geir Ove Myhr (gomyhr)]

This marked as 8.10 (Intrepid) in the upstream bug, but the X and intel driver version seems to be compatible with 8.04 (Hardy). What version is this for?

[Jerone Young (jerone)]

Not seeing this bug. Here is why:

So as of late I have learned that you cannot just use the pm-* commands without playing with the hardware clock or what not.

When I run this exact same test, but instead of using pm-hibernate, I go to the gnome menu and hiberate. I do not see this issue.

[Torsten Spindler (tspindler)]

When using the GUI hibernation (battery -> hibernate) I get a halfway shown 3D window, see the attached screenshot. The right side is black. When toggling between the 3D window and 2D window, the attached screenshot is seen every second time.

[Jerone Young (jerone)]

I spoke too soon on my last post. I eventually did see the netbook remix menu went all white. Then after switching between virtual terms, it was back to normal.

Just tried intrepid and it appears that it does not have this issue. I have my desktop using compiz and it is not having the same type issue.

[Torsten Spindler (tspindler)]

When it works in Intrepid, we can use this driver version on Hardy and see if the bug occurs:
https://edge.launchpad.net/ubuntu/intrepid/+source/xserver-xorg-video-intel/2:2.4.1-1ubuntu10

[Torsten Spindler (tspindler)]

I compiled the 2.4.1 sources and used them, the behavior is the same.

Here the relevant part from /var/log/Xorg.0.log

(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
        compiled for 1.4.0.90, module version = 2.4.1
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 2.0

[Torsten Spindler (tspindler)]

The bug disappears when doing a single switch to virtual console and back after suspend or hibernation.

[Torsten Spindler (tspindler)]

The switch to virtual console and back has to come after the resolution change.

[Torsten Spindler (tspindler)]

This bug occurs on Ubuntu 8.04.1 Hardy, not on Ubuntu 8.10 Intrepid.

[Jesse Barnes (jbarnes-virtuousgeek)]

So this isn't a 2D driver bug right, since you tried the Intrepid version of the 2D driver on Hardy and things were still broken?

The first thing (since it's easy) to try would be to update the kernel on the Hardy config to 2.6.27+ and see if that fixes things, since newer kernels contain suspend/resume support for Intel GPUs. Beyond that it could be a server bug that was fixed recently or a Mesa issue; the problem doesn't ring a bell, but at least it sounds like it's fixed in more recent versions of things (please re-open if you see it again).

[Bryce Harrington (bryce)]

Ah, that rules out a change in -intel. Unfortunately that makes this quite a bit harder to solve since we don't know what component it is.

We really need a clue from upstream to be able to make any progress on this. I'll re-ping them.

There are several components involved in 3D, any of which could be the source of the problem: a) kernel, b) xserver, c) mesa, d) other/misc.

So, unless we get more specific guidance from upstream, one next step would be to test downgrading each of these in turn. Mesa and Xserver have interdependencies, so downgrading them individually may be hard.

Another approach would be to test the Alpha 1, 2, 3, 4, 5 CD's. Since various components were upgraded at different points of time, possibly this could help narrow down roughly when the issue started.

[Bryce Harrington (bryce)]

In talking with Jesse:

<bryce> re bug 18360 again... Torsten found it does not occur on Intrepid, so presumably a patch exists somewhere.
<bryce> however he compiled the 2.4.1 driver that worked on Intrepid, on Hardy and the issue still occurs, so it sounds like the fix could be in mesa, xserver, or the kernel...
<jbarnes> ah ok yeah could be any of the other bits too
<bryce> unfortunately with the playing field that wide, it's hard to know where to look next... advice?
<jbarnes> I'd start with the X server
 you'd have to troll through the logs since the version you had in hardy to see if there's anything dri relevant
 dri & randr relevant that is
<bryce> ok, thanks, that does narrow it down some

[Torsten Spindler (tspindler)]

Running the 2.6.27-7-generic kernel does not fix the problem.

[Bryce Harrington (bryce)]

Hi Jesse,

Torsten has found that using the newer versions of the kernel, -intel, and mesa did not resolve the issue. So, presumably, it is the xserver which fixes it. But backporting xserver (along with all its dependencies), is very non-trivial.

I grepped through the xserver Changelog but found nothing, however I'm not sure what keywords would be most appropriate to use in the search. Could you offer some suggestions?

[Jesse Barnes (jbarnes-virtuousgeek)]

No, I took a quick look through the X server git log too, but nothing jumped out. You'd have to walk through the VT switch and startup code paths to see where the fix may have been committed. Or if it's easy to reproduce on the system you could try bisecting through the X server commits for the fix; it might be a pain due to dependencies though... Anyway I'll mark fixed since it sounds like upstream is ok here.

[quanxian (quanxian-wang)]

Jesse,
I ever provide the patch(2D) to ubuntu. The patch will be fix this bug. However it will bring others problems. :(

I doubt I change the wrong location. The original thought is we think front_buffer, back_buffer, depth_buffer is changed after resume, therefore after the resume, we need to remap it. However I put this source code in mode setting, that is means whatever you change resolution, you have to update this. It is not reasonable. Do you have some suggestion where to add this after resume or how to check the condition. I am testing to check if front_buffer, back_buffer, depth_buffer is NULL or not and then change it.

Here are the patches
--- i830_lvds.c_orig 2008-11-30 10:41:11.000000000 -0500
+++ i830_lvds.c 2008-11-30 10:41:37.000000000 -0500
@@ -537,6 +537,11 @@ i830_lvds_mode_set(xf86OutputPtr output,
     I830CrtcPrivatePtr intel_crtc = output->crtc->driver_private;
     CARD32 pfit_control;

+#ifdef XF86DRI
+ /* 945GME quirk process */
+ if (IS_I945GM(pI830) && !i830_update_dri_buffers(pScrn))
+ FatalError("i830_update_dri_buffers() failed\n");
+#endif
     /* The LVDS pin pair will already have been turned on in
      * i830_crtc_mode_set since it has a large impact on the DPLL settings.
      */

I

[quanxian (quanxian-wang)]

Ubuntu has accept the patch and follow up it by deleting the line
+ FatalError("i830_update_dri_buffers() failed\n");

After that, I checked the code, seems it will not bring effect. The reason is when you apply the map based on the current offset, there are two conditions.
1) you have mapped the offset
it will return fail, because you have mapped before, there is a map in the list based on your offset of buffer. We can ignore it because we have gotten what we want.
2) we don't mapped this offset
it will return success, this is just want we want for this bug. Because there is some offest changed, and no map happens, it will bring some effect to xserver. Therefore we run this will solve the problem.

As a summary, deleting this line will be OK from my understanding.

Quanxian Wang

[quanxian (quanxian-wang)]

Jesse,
If you think it is OK, you can close this bug. If you have some others comment, just go on.

Anyway, I just get the result from the source code. I don't make some consideration with other possible effect.

[Jesse Barnes (jbarnes-virtuousgeek)]

Ok, thanks for checking it out, since Ubuntu is happy with it now and upstream is fixed, I'll close.

[Simon Holm (odie-cs)]

Uhm, according to the upstream bug it seems that "Ubuntu" has been made aware of a fix. See from comment #7 and down in upstream report. Have this made it into the updates for Hardy and can this bug be closed?

[Bryce Harrington (bryce)]

Leaving task for the hardy backport; closing development task for karmic.

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".