I've got a 965GM test machine I can use, I'll try to reproduce this.

The suspend/resume does not actually make display corruption, the VT switch does. 

Steps to reproduce:
use latest drm/dri kernel modules
use Xserver 1.4.1
start the Xserver
run any movie via textured video
do VT switch
display is corrupted.

I noticed that DSPBSURF gets changed on VT switch if a movie has been played.

VT switch without movie does not change DSPBSURF value.

The patch (commit id 9536515d7717969795edc1b80d6e6a36820dd575) seems to fix this problem according to the bug reporter. So close it now.

Thanks,
hong

From Lukas:

Today, I discovered that the bug is still present, it just does not occur so
often. I.e., some random bo_list corruption is still present in driver/dri.

Hong, didn't you already fix the bo_list corruption?  If so, is this bug actually fixed?

(In reply to comment #6)
> Hong, didn't you already fix the bo_list corruption?  If so, is this bug
> actually fixed?
> 

I can test it as soon as drm git will compile with 2.6.25-rc kernels.

You should be able to just use the 2.6.25-rc bits directly, the DRM suspend/resume code is upstream as of 2.6.25-rc1 iirc.

(In reply to comment #8)
> You should be able to just use the 2.6.25-rc bits directly, the DRM
> suspend/resume code is upstream as of 2.6.25-rc1 iirc.
> 

but stock DRM does not contain TTM code, does it? I saw the bo_list corruption only with TTM enabled DRM which is in git only.

Oh right, yeah they don't contain the TTM bits.  dri-devel may have patches to fix the DRM build with recent kernels...

Oops, accidentally reassigned.

(In reply to comment #7)
> I can test it as soon as drm git will compile with 2.6.25-rc kernels.

It seems that the latest git of xorg intel driver and dri driver fix this bug. So I guess it can be closed.

Ok, thanks for testing Lukas.  Sounds like things are slowly becoming solid & reliable for you. :)

(In reply to comment #13)
> Ok, thanks for testing Lukas.  Sounds like things are slowly becoming solid &
> reliable for you. :)
> 

Unfortunately, I have seen this bug again today. I noticed that before suspend and before any other previous suspend, the frame buffer location was:
(II) intel(0): 0x01f00000-0x02a7bfff: front buffer (11760 kB) X tiled

After resume that do not have the bug the front buffer location is the same. However, if the display is corrupted, the allocation looks like:
(II) intel(0): 0x02000000-0x02b7bfff: front buffer (11760 kB) X tiled

The complete layout is the following:
(bad one)
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x0077f000:            start of memory manager
(II) intel(0): 0x0077f000-0x0083afff: xv buffer (752 kB)
(II) intel(0): 0x0083b000-0x013b6fff: depth buffer (11760 kB) Y tiled
(II) intel(0): 0x013b7000-0x01f32fff: back buffer (11760 kB) X tiled
(II) intel(0): 0x02000000-0x02b7bfff: front buffer (11760 kB) X tiled
(II) intel(0): 0x02b7c000-0x02b7cfff: overlay registers (4 kB)
(II) intel(0): 0x02b7d000-0x02b8cfff: exa G965 state buffer (64 kB)
(II) intel(0): 0x02b8d000-0x02b94fff: logical 3D context (32 kB)
(II) intel(0): 0x02b95000-0x02b9efff: HW cursors (40 kB)
(II) intel(0): 0x0bd8c000:            end of memory manager

(good one)
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x0077f000:            start of memory manager
(II) intel(0): 0x0077f000-0x012fafff: depth buffer (11760 kB) Y tiled
(II) intel(0): 0x012fb000-0x01e76fff: back buffer (11760 kB) X tiled
(II) intel(0): 0x01f00000-0x02a7bfff: front buffer (11760 kB) X tiled
(II) intel(0): 0x02a7c000-0x02a7cfff: overlay registers (4 kB)
(II) intel(0): 0x02a7d000-0x02a8cfff: exa G965 state buffer (64 kB)
(II) intel(0): 0x02a8d000-0x02a94fff: logical 3D context (32 kB)
(II) intel(0): 0x02a95000-0x02a9efff: HW cursors (40 kB)
(II) intel(0): 0x0bd8c000:            end of memory manager


So there is the xv buffer as an addition in the bad one. It looks like Xserver does not handle front buffer relocation correctly?

Also there is serious memory corruption resulted from this, see the attached dmesg.

Created attachment 15329 [details]
memory corruption output.

Yeah, it looks like movement isn't handled properly with the new TTM bits.  Could be a DRM, 2D or server problem...

I've been sitting on this because the TTM & mode setting stuff has been in so much flux.  Now we're moving to a new memory manager, so I think we can safely mark this as wontfix...