xorg-server: X.Org X Server 220.127.116.111 (1.6.2 RC 1), Release Date: 2009-5-8
kernel: 2.6.30 gentoo-sources-2.6.30-r1, tuxonice patch applied
After resume from hibernation, decorations are missing (using emerald) and cannot be restored with `emerald --replace' but only by restarting compiz. Other effects are not working, too, like zoom when opening windows.
This can be easily solved by running compiz-manager to kill and restart emerald and compiz.
Steps to reproduce:
1. Start compiz.
. Compiz works partially (some effects don't work anymore, decoration is missing even when restarting emerald), everything else works fine.
. Everything's working fine.
glxgears runs fine with hibernate and resume.
I'll attach intel_gpu_dump output after resume, with compiz misbehaving.
Other patches applied:
compiz glxDestroyPixmap changed like suggested in bug #20704, comment #48.
Nothing else (not using Eric Anholt's intel-drm anymore since I was not able to merge it into my git repo without issues).
Created attachment 27035 [details]
intel_gpu_dump output when compiz works only partially.
GPU dump output as announced in initial post. Too big to submit without compressing, sorry for that.
Created attachment 27323 [details] [review]
restore the modeset for every activated crtc
Will you please try the attached patch on the latest linus git tree and see whether the issue still exists after hibernation?
Thanks for the patch, I applied it on my current kernel. Unfortunately, this did not change anything.
Currently, I don't have time to test it on the latest linus git tree, maybe I'll try later.
Thanks for the test.
Please try to test it on the latest linus git tree and I am looking forward to the test result.
I've cloned tuxonice-head (tracking linus' head), applied your patch, (tested hibernate/resume again,) pulled Eric Anholt's drm-intel-next repository.
It does not make a difference, still the same issues. Sorry, your patch does not help.
Additionally (in all kernel versions tested so far), the backlight is turned off at atomic copy, but not restored at resume. This is a bit annoying too.
Thanks for the test.
Maybe the compiz issue is not related with the suspend/resume.
Will you please do the following test and see whether the compiz still can work well ?(This had better be done on the latest linus git tree. Of course the 2.6.31-rc2 is also ok).
a. boot the system with KMS disabled and enter the X-environment
b. start compiz and then switch to the console mode by using the command of "chvt 2"
c. use the tool of intel_gpu_dump to get the gpu dump
d. switch to the X again by using "chvt 7" and see whether the compiz still can work well?
This issue can be reproduced on another laptop. After doing suspend/resume, the compiz can't work well.
Then I do the following test on the box
1. boot the system with KMS disabled
2. Start x and start compiz window
3. switch to the console mode by using chvt.
4. switch to the X again by using chvt and find that compiz can't work well.
When it switches to console mode by using chvt, the ring buffer will be flushed. And after it switches to X mode again, the compiz can't work well.
But if mode switch is tested in KMS mode, the compiz can work well. And the ring buffer won't be flushed in KMS mode when we switch the mode between console and X.
In fact when we do the suspend/resume, we will have to flush the ring buffer. In such case it brings that the compiz can't work well.
So IMO this issue is not related with suspend/resume. Maybe it is related with how the ring buffer is handled.
assign this non-suspend/resume bug away from ykzhao.
Jesse, could you take a look?
Could be ring flushing... but it could also be the way we handle GTT bind/unbind across VT switch (in UMS mode) and hibernation. In both of those cases we'll be rebuilding the GTT from scratch, whereas KMS VT switch is much lighter weight; it'll just change modes and switch buffers.
I think we're probably missing some restore code in both cases. OpenGL clients like compiz expect their textures to be available whenever they access them...
Is it possible for you to try using a KMS configuration? We're trying to deprecate the UMS code for various reasons (suspend/resume fragility among them).
I've used KMS before.
Whatever, after upgrading to kernel-2.6.31 and with latest versions of mesa, drm and intel drivers, everything is fine now.
Thanks for your help.