Bug 23254 - Compiz doesn't survive suspend/resume cycle
Summary: Compiz doesn't survive suspend/resume cycle
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Eric Anholt
QA Contact:
Depends on:
Reported: 2009-08-11 09:22 UTC by maximlevitsky
Modified: 2009-09-09 18:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

versions of graphics stack (9.48 KB, text/plain)
2009-08-11 09:22 UTC, maximlevitsky
dmesg (153.42 KB, text/plain)
2009-08-11 21:36 UTC, maximlevitsky
GPU dump (111.30 KB, application/x-bzip)
2009-08-11 22:16 UTC, maximlevitsky
xorg.log (24.34 KB, text/x-log)
2009-08-15 01:22 UTC, maximlevitsky

Description maximlevitsky 2009-08-11 09:22:27 UTC
Created attachment 28518 [details]
versions of graphics stack

Sometime ago compiz finally have surviving suspend resume cycle.
commit 0f328c90dbc893e15005f2ab441d309c1c176245 however breaks it again.

Sympthoms are that ether it freezes or, it can't draw new windows. Also it would display a black cube when rotated.

These are same symptoms as before it was fixed.

Commit is revertible, and doing so makes compiz work just fine after a suspend resume cycle.

Kernel is vanilla 90bc1a658a53f8832ee799685703977a450e5af9

Always reproducible, and without this commit, compiz is very stable at surviving suspend/resuming.


Section "Device"
  identifier "Intel"
  boardname "Intel 965"
  busid "PCI:0:2:0"
  driver "intel"
  screen 0

  Option "XvMC" "true"

Section "Screen"
	Identifier "Default Screen"
	Device     "Intel"
	DefaultDepth     24

Section "ServerLayout"
  Identifier "Default Layout"
  screen 0 "Default Screen" 0 0
Comment 1 Eric Anholt 2009-08-11 10:46:32 UTC
I've been suspending/resuming with compiz running for weeks now with no problem, including with that commit.  Could you post intel_gpu_dump output, along with Xorg.0.log and dmesg? (xorg.conf doesn't contain information these days)
Comment 2 maximlevitsky 2009-08-11 21:36:20 UTC
Created attachment 28530 [details]
Comment 3 maximlevitsky 2009-08-11 21:38:01 UTC
I tested this again, now without my ad hackish fix for bursty fps in kernel (now kernel is pure vanilla 90bc1a658a53f8832ee799685703977a450e5af9)

This is 100% reproducible.

Like I said, system/compiz doesn't hang completely after resume.
It seems not to be able to allocate textures? 
I see all existing windows, new windows aren't shown, rotated cube is black except panels.

I doubt that I could get anything reasonable from ring buffer dump at that stage.

I have i965 DG965RY motherboard.

All GPU stack is build (like I said) from source.

It is very surprising to see some very nice improvements in the stack.
without the above commit, I couldn't hang the system by doing the suspend/resume cycle while running any 3d program, including googleearth, which finally works just fine.
Comment 4 maximlevitsky 2009-08-11 22:16:09 UTC
Created attachment 28535 [details]
GPU dump

This is a GPU dump
I did it twice after resume

Note that compiz doesn't completely stuck.
For example it does show new windows of nautilus, but without decoration, it doesn't show new windows of gnome-terminal, and cube is black like I said
Comment 5 maximlevitsky 2009-08-15 01:22:36 UTC
Created attachment 28643 [details]

Forgot to add xorg.log
Comment 6 maximlevitsky 2009-08-15 01:30:11 UTC
Any way I can help with that?

Surprisingly, latest intel drivers (+ this commit reverted) work very well in regard to suspend/resume.

In fact they even have passed my torture test:

I start googleearth (which always hung the system on resume), neverball, tuxracer (and start a level), torcs, and a movie in totem, then do a suspend/resume cycle (everything under compiz of course). And it works!

Currently, what still sucks is custom shaders support (even assembly ones)

For example, both water and reflection in compiz hang system hard, GE's atmosphere is white.... (but there is a progress, water effect in GE does work now)

Don't know if this is worth another bugreport, you probably are well aware of this.

Let me know, if I can help more on that issue
Comment 7 maximlevitsky 2009-09-06 14:52:31 UTC
Any progress on that?

I didn't get any response anywhere.
Comment 8 Eric Anholt 2009-09-09 13:04:00 UTC
Verified that this fixed it here:

commit 5604b27b9326ac542069a49ed9650c4b0d3e939a
Author: Eric Anholt <eric@anholt.net>
Date:   Wed Sep 9 12:35:30 2009 -0700

    i965: Fix relocation delta for WM surfaces.
    This was a regression in 0f328c90dbc893e15005f2ab441d309c1c176245.
    Bug #23688
    Bug #23254

Comment 9 maximlevitsky 2009-09-09 18:42:31 UTC
It is indeed fixed!
Thank you very much!

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.