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

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

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

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).

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?

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.

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

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

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. 

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