I'm using a Radeon Mobility X1400 with KMS (kernel: rc6). After I do a suspend to ram + resume the output consists of vertical bars that often - but not always change colors. There is no way to identify anything of the desktop's contents. I'll attach an archive to the bug containing: resume.log: contents of /var/log/messages with everything before and after the resume removed - the log itself is complete. script.log: lspci, git commands showing which exact version of libdrm, xf86-video-ati and mesa I'm using, glxinfo, uname Xorg.0.log, Xorg.0.log.old, kdm.log, xorg.conf: Just to be complete.
Created attachment 28872 [details] The archive mentioned
Created attachment 28873 [details] lspci -v
Created attachment 28874 [details] r100_rbbm_info
The system is opensuse 11.1 with all the necessary components updated to be able to run kms (kernel, X, libdrm, radeon driver, mesa). The suspend is done via "powersave -u". vbetool is not installed.
Created attachment 28875 [details] log of resume
Made some tests with powersaving: echo mem >/sys/power/state s2ram powersave -u Results: echo and s2ram work, when run from a vt, they don't when run from X; powersave never works I'll attach the output of dmesg from the resume of echo.
Created attachment 28876 [details] output of dmesg of resume
Just as an addition to #6: X is fine after the resume as long as echo or s2ram were run from a vt and not from X.
Created attachment 28879 [details] result of dmesg after broken resume from echo on x OK, some more experimenting results in: - echo and s2ram do not always break when run from X, just often (2 out of ~10 were not broken) - once it is broken, it is possible to reliably revive the vt by loggin in remotely, chvt 1, running s2ram again and then resuming. I did not manage to revive X that way (even restarting X after such a procedure didn't work).
Created attachment 28880 [details] dmesg after saving/resuming via powersave -u
Duplicate of bug 23290
Just to add an update: The corruption also occurs on vt1 with s2ram and "echo mem >/sys/power/state", just not always but sometimes. Sometimes means: s2ram/echo on vt1 work up 3-10 times in a row, or it may fail immediately. So far I haven't found a way to predict was will happen.
Reading http://airlied.livejournal.com/68550.html from describes how the bug was fixed. Link to the fix: http://people.freedesktop.org/~airlied/scratch/0002-drm-radeon-kms-read-back-register-before-writing-in-.patch The bug can also be found in redhats bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=527874 where it is marked as fixed. Unfortunately that is not where non-redhat/fedora users would look :-( I can confirm that this fixes my problem. Closing as duplicate of 23290 *** This bug has been marked as a duplicate of bug 23290 ***
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.