Bug 541562
|
Description
Alex Tucker
2009-11-26 11:06:16 UTC
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 2.6.31.6-156 should be in koji in a couple of hours, with a rv4xx s/r fix. Just tried with 2.6.31.6-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 2.6.31.6-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 2.6.31.6-157.fc12.x86_64
Created attachment 375055 [details]
Output from "radeontool regs" after suspend/resume, kernel 2.6.31.6-157.fc12.x86_64
Created attachment 375063 [details]
/var/log/messages, from boot to just before suspend, kernel 2.6.31.6-157.fc12.x86_64
Created attachment 375065 [details]
/var/log/messages, from just after suspend, kernel 2.6.31.6-157.fc12.x86_64
Created attachment 375074 [details]
dmesg with drm.debug=1, from boot to before suspend, kernel 2.6.31.6-157.fc12.x86_64, spurious drm_ioctl filtered out
Created attachment 375075 [details]
dmesg with drm.debug=1, from after suspend, kernel 2.6.31.6-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 2.6.31.6-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 2.6.31.6-159.fc12.x86_64, spurious drm_ioctl filtered out
Created attachment 375398 [details] dmesg with drm.debug=1, from after suspend, kernel 2.6.31.6-159.fc12.x86_64, spurious drm_ioctl filtered out Tried kernel 2.6.31.6-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 2.6.31.6-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 2.6.31.6-161.fc12.x86_64, spurious drm_ioctl filtered out
kernel 2.6.31.6-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. 2.6.31.6-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-2.6.31.6-162.fc12.i686 package. *** Bug 546862 has been marked as a duplicate of this bug. *** I have a corrupted display during boot with kernel-2.6.31.6-161.fc12.i686 kernel-2.6.31.6-160.fc12.i686 is doing fine for me Hardware : ATI Mobility Radeon X700 PCIE The corruption i have is the same as : https://bugzilla.redhat.com/attachment.cgi?id=377859 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. http://koji.fedoraproject.org/koji/taskinfo?taskID=1882547 will point to a scratch build in http://koji.fedoraproject.org/scratch/airlied/ 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) > http://koji.fedoraproject.org/koji/taskinfo?taskID=1882547 > > will point to a scratch build in > > http://koji.fedoraproject.org/scratch/airlied/ > > 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 kernel: 2.6.32-14.20091218.drm_radeon_testing.fc12.i686 just a system freeze i attached the content of pm-suspend Created attachment 381111 [details]
pm-suspend.log
Created attachment 381120 [details]
dmesg
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' rpmdev-setuptree *** note that you home partition should have free space >= 10 GB *** mv linux-2.6.32.tar.bz2 ~/rpmbuild/SOURCES cd ~/rpmbuild/SOURCES export CVSROOT=:pserver:anonymous.org:/cvs/pkgs cvs co kernel/devel mv kernel/devel/* . now download the spec file that i attached to ~/rpmbuild/SPECS cd ~/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 ~/rpmbuild/RPMS/<your_arch> 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/3/hibr: ok UMS/5/susp: can't test due bug 542275 UMS/5/hibr: can't test due bug 542275 KMS/3/susp: blank screen KMS/3/hibr: ok KMS/5/susp: blank screen KMS/5/hibr: ok 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. Thanks. @Daniel did u use any pm-hibernate quirks ? My machine is still freezing when trying to suspend. Major involved components I am having : kernel-2.6.32.3-10.fc12.i686 xorg-x11-drv-ati-6.13.0-0.20.20091221git4b05c47ac.fc12.i686 xorg-x11-server-Xorg-1.7.4-1.fc12.i686 libdrm-2.4.17-1.fc12.i686 mesa-libGL-7.7-1.fc12.i686 > 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 2.6.32.3-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. kernel-PAE-2.6.33.2-57.fc13.i686 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 2.6.31.6-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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 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: 2099810f903caa1920f3ef6014fb7f36e4786490 drm/radeon: enable pci bus mastering after card is initialised (v2) https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=2099810f903caa1920f3ef6014fb7f36e4786490 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. |