User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/18.104.22.168 Safari/532.5
Suspend to RAM now resumes with KMS on my Acer Ferrari 4005 laptop with a Radeon Mobility X700, however the screen comes up corrupted and there doesn't appear to be a way to reset it.
Steps to Reproduce:
1. Suspend to ram, e.g. sudo pm-suspend.
2. Wake system, e.g. pressing a key
System suspends and resumes correctly but for the display, which while just about readable is corrupted in the sense that the width seems squeezed by 1/2 inch, the colours dance around and the horizontal lines flicker.
Previously on Fedora 11, using KMS didn't allow for suspend and resume and I had to use the "nomodeset" kernel option. This no longer works in Fedora 12, but that's another bug report and I guess you're more interested in getting KMS working properly.
Created attachment 373961 [details]
Xorg.0.log before suspend/resume
Created attachment 373964 [details]
smolt profile for Ferrari 4005 laptop
Created attachment 373965 [details]
copy of /var/log/dmesg (with drm.debug=1 on kernel commandline)
Created attachment 373968 [details]
copy of /var/log/messages from boot, with drm.debug=1, before suspend/resume
Created attachment 373972 [details]
Photo of screen after resume.
Static photo obviously doesn't show the shaky horizontal fuzzing.
Created attachment 373973 [details]
Copy of /var/log/messsages after resume, snipped to remove previous logs
Created attachment 373974 [details]
output from dmesg after resume
May have missed the actual resume as my baby daughter woke up whilst in the middle of this :(
Created attachment 373975 [details]
Xorg.0.log after suspend/resume
Created attachment 373977 [details]
Output from "radeontool regs" from before suspend/resume
Created attachment 373978 [details]
Output from "radeontool regs" after suspend/resume
Please capture log with drm.debug=1 most of the time debug is printing useless stuff.
Created attachment 374040 [details]
Captured all kernel messages during suspend/resume cycle
System booted at Nov 26 16:40:07, put to sleep and resumed at 16:42:14.
Updated to xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12.x86_64 but no difference.
Can you try latest kernel?
kernel 22.214.171.124-156 should be in koji in a couple of hours, with a rv4xx s/r fix.
Just tried with 126.96.36.199-157.fc12.x86_64, but no luck. If anything, the display is worse: the first time I tried suspend/resume, I just got wide vertical white stripes; the second time I got the attached. Will further attach drm.debug messages (modulo the [drm:drm_ioctl] lines), etc.
Created attachment 375053 [details]
Photo of display artifacts (ignore the reflection of the back garden) with kernel 188.8.131.52-157.fc12.x86_64.
Note that the horizontal lines are constantly moving left/right and the whole display shimmers quite dramatically. A pm-hibernate froze the shimmering for a few seconds.
Created attachment 375054 [details]
Output from "radeontool regs" from before suspend/resume, kernel 184.108.40.206-157.fc12.x86_64
Created attachment 375055 [details]
Output from "radeontool regs" after suspend/resume, kernel 220.127.116.11-157.fc12.x86_64
Created attachment 375063 [details]
/var/log/messages, from boot to just before suspend, kernel 18.104.22.168-157.fc12.x86_64
Created attachment 375065 [details]
/var/log/messages, from just after suspend, kernel 22.214.171.124-157.fc12.x86_64
Created attachment 375074 [details]
dmesg with drm.debug=1, from boot to before suspend, kernel 126.96.36.199-157.fc12.x86_64, spurious drm_ioctl filtered out
Created attachment 375075 [details]
dmesg with drm.debug=1, from after suspend, kernel 188.8.131.52-157.fc12.x86_64, spurious drm_ioctl filtered out
could to boot with nomodeset and attach the /var/log/Xorg.0.log?
Created attachment 375227 [details]
Xorg log after booting with nomodeset, also through suspend/resume cycle.
okay we spotted a bug that might explain this, I'll try and build a kernel with it tomorrow or later today.
okay I'm building 184.108.40.206-159 in koji please give a try when it lands.
if it doesn't work updated dmesgs would be nice.
Created attachment 375397 [details]
dmesg with drm.debug=1, from boot to before suspend, kernel 220.127.116.11-159.fc12.x86_64, spurious drm_ioctl filtered out
Created attachment 375398 [details]
dmesg with drm.debug=1, from after suspend, kernel 18.104.22.168-159.fc12.x86_64, spurious drm_ioctl filtered out
Tried kernel 22.214.171.124-159.fc12.x86_64 from koji, but it didn't seem to make any difference -- the display looks the same as the last photo (attachment 375053 [details]).
okay another attempt at a fix is about to start building koji in 126.96.36.199-161
let me know how it goes.
Created attachment 375754 [details]
dmesg with drm.debug=1, from boot, through a couple of suspend/resumes, kernel 188.8.131.52-161.fc12.x86_64, spurious drm_ioctl filtered out
kernel 184.108.40.206-161.fc12.x86_64 seems to fix the display problems after a resume, but introduces some display shimmering before suspending. I.e. starting from a cold boot, the display is slightly corrupted (will attach short phone video) and then a suspend/resume cycle seems to clear it.
Created attachment 375755 [details]
Phone video of display corruption during and after boot
Okay I'll try and get another patch out next week, we at least are very close to narrowing it down.
220.127.116.11-162.fc12.x86_64 seems to fix a similar problem with the X1300 (M52).
I now get corruption-free resumption on my Thinkpad T60 after suspension or hibernation. Have not tested this on multiple screens yet. However, you freakin' rock!
Correction: I'm using the kernel-PAE-18.104.22.168-162.fc12.i686 package.
*** Bug 546862 has been marked as a duplicate of this bug. ***
I have a corrupted display during boot with kernel-22.214.171.124-161.fc12.i686
kernel-126.96.36.199-160.fc12.i686 is doing fine for me
ATI Mobility Radeon X700 PCIE
The corruption i have is the same as :
I've reverted that 161 test patch in the 174 kernel build.
I don't suppose anyone with an rv410 laptop wants to install and test a kernel from git? it'll make life a lot easier for a feedback loop. considering
fedora kernel builds can take 5-6 hrs.
will point to a scratch build in
with another test fix for the boot + s/r cases.
always a corrupted display upon boot with this kernel+libdrm
plus, X server hangs
(In reply to comment #38 and #39)
> will point to a scratch build in
> with another test fix for the boot + s/r cases.
Sorry for the late response. Has this been cleaned, as I can't find anything related in the above links.
In response to tracking a git repo and building locally, that's fine with me, just point me to the URI.
no suspend with latest git
just a system freeze
i attached the content of pm-suspend
Created attachment 381111 [details]
Created attachment 381120 [details]
for testers interested in airlied's git tree :
*** choose a partition where you have enough space, let's say >= 600MB ***
git clone --depth 10 git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
git checkout -b drm-radeon-testing origin/drm-radeon-testing
mv drm-2.6 linux-2.6.32
tar cjf linux-2.6.32.tar.bz2 linux-2.6.32
su -c 'yum install fedora-packager'
*** note that you home partition should have free space >= 10 GB ***
mv linux-2.6.32.tar.bz2 ~/rpmbuild/SOURCES
cvs co kernel/devel
mv kernel/devel/* .
now download the spec file that i attached to ~/rpmbuild/SPECS
rpmbuild -bb kernel.spec
now do something else, coz it gonna take some time :)
when the build finishes, you will find your kernel at
Created attachment 381126 [details]
spec file to use for the build
i used to be able to suspend at least, but not now.
trying to suspend freezes the system
i tried downgrading libdrm, and hal. no results so far
I tested a lot suspend/hibernate on my Acer laptop with X700 and got these results from different UMS/KMS/runlevel combinations and testing with different pm-suspend options:
UMS/3/susp: blank screen, can type commands
UMS/5/susp: can't test due bug 542275
UMS/5/hibr: can't test due bug 542275
KMS/3/susp: blank screen
KMS/5/susp: blank screen
So it seems hibernate works all ok in everycase but suspend is totally busted. I have Fedora 12 + all updates as of 2010-01-10. In logs I see now errors at all, only successes and normal behaviour are being reported.
did u use any pm-hibernate quirks ?
My machine is still freezing when trying to suspend.
Major involved components I am having :
> did u use any pm-hibernate quirks?
No, hibernate worked ok by default. I tried with several pm-suspend quirks and quirk combinations but nothing seemed to helped.
please try 188.8.131.52-24, it should fix failure to suspend (not resume ;-)
this still affects me in both fedora 11, latest updates as of 02.03.2010, as well as on Fedora 12 (32bit)
With F13ß my Acer laptop with X700 survives hibernate/resume but when doing suspend/resume the screen remains blank after resume.
As the original reporter, I can no longer help debugging this as the laptop is sadly no longer working.
Up until a couple of months ago, I had tried with each new kernel, but always saw pretty much the same results and resorted to using kernel 184.108.40.206-161.fc12.x86_64 from comment 29.
I'll move on to opening reports for all the display and suspend resume bugs on my new laptop...
I am having the same artifacts after resume as comment 16 with latest Fedora 14 i686.
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
still exists on rawhide
FWIW, I filed Bug 710243 for Fedora 15 with complete set of logs - suspend works but resume fails as described here.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
This problem still exists with the 3.9 kernel. Regardless of whether I'm using modesetting or not. (I.e. I get a blank screen after resuming from a suspend, even if the radeon driver isn't loaded.)
I got booting with KMS working by undoing kernel patch:
drm/radeon: enable pci bus mastering after card is initialised (v2)
I got resuming-from-suspend to work by installing app-laptop/radeontool and executing the following after resuming from a suspend:
radeontool light off
radeonreg regset 0x00000284 0x1bd34208
radeonreg regset 0x000002d0 0x003c00a1
radeonreg regset CL:03 0x001c0007
radeonreg regset CL:04 0x0002004a
radeonreg regset CL:05 0x0002004a
radeonreg regset CL:06 0x0002004a
radeontool light on
(You can find what those values probably should be while it's working with "radeonreg regmatch CL:03" etc.)
As per comment 55, I can no longer help with this bug, so I'm closing.