Bug 541562 - KMS:RV410:M26:X700 resume from suspend gives corrupted display
Summary: KMS:RV410:M26:X700 resume from suspend gives corrupted display
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 19
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jérôme Glisse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: card_R420/mM
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-26 11:06 UTC by Alex Tucker
Modified: 2018-04-11 08:22 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-23 11:44:37 UTC
Type: ---


Attachments (Terms of Use)
Xorg.0.log before suspend/resume (61.15 KB, text/plain)
2009-11-26 11:11 UTC, Alex Tucker
no flags Details
smolt profile for Ferrari 4005 laptop (6.82 KB, text/plain)
2009-11-26 11:13 UTC, Alex Tucker
no flags Details
copy of /var/log/dmesg (with drm.debug=1 on kernel commandline) (36.32 KB, text/plain)
2009-11-26 11:15 UTC, Alex Tucker
no flags Details
copy of /var/log/messages from boot, with drm.debug=1, before suspend/resume (63.17 KB, text/plain)
2009-11-26 11:17 UTC, Alex Tucker
no flags Details
Photo of screen after resume. (3.56 MB, image/jpeg)
2009-11-26 11:31 UTC, Alex Tucker
no flags Details
Copy of /var/log/messsages after resume, snipped to remove previous logs (17.73 KB, text/plain)
2009-11-26 11:33 UTC, Alex Tucker
no flags Details
output from dmesg after resume (122.88 KB, text/plain)
2009-11-26 11:35 UTC, Alex Tucker
no flags Details
Xorg.0.log after suspend/resume (67.42 KB, text/plain)
2009-11-26 11:36 UTC, Alex Tucker
no flags Details
Output from "radeontool regs" from before suspend/resume (527 bytes, text/plain)
2009-11-26 11:37 UTC, Alex Tucker
no flags Details
Output from "radeontool regs" after suspend/resume (522 bytes, text/plain)
2009-11-26 11:38 UTC, Alex Tucker
no flags Details
Captured all kernel messages during suspend/resume cycle (2.92 MB, text/plain)
2009-11-26 17:14 UTC, Alex Tucker
no flags Details
Photo of display artifacts (ignore the reflection of the back garden) with kernel 2.6.31.6-157.fc12.x86_64. (416.78 KB, image/jpeg)
2009-12-01 13:14 UTC, Alex Tucker
no flags Details
Output from "radeontool regs" from before suspend/resume, kernel 2.6.31.6-157.fc12.x86_64 (527 bytes, text/plain)
2009-12-01 13:17 UTC, Alex Tucker
no flags Details
Output from "radeontool regs" after suspend/resume, kernel 2.6.31.6-157.fc12.x86_64 (522 bytes, text/plain)
2009-12-01 13:18 UTC, Alex Tucker
no flags Details
/var/log/messages, from boot to just before suspend, kernel 2.6.31.6-157.fc12.x86_64 (62.07 KB, text/plain)
2009-12-01 13:40 UTC, Alex Tucker
no flags Details
/var/log/messages, from just after suspend, kernel 2.6.31.6-157.fc12.x86_64 (6.32 KB, text/plain)
2009-12-01 13:41 UTC, Alex Tucker
no flags 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 (72.24 KB, text/plain)
2009-12-01 14:35 UTC, Alex Tucker
no flags Details
dmesg with drm.debug=1, from after suspend, kernel 2.6.31.6-157.fc12.x86_64, spurious drm_ioctl filtered out (14.38 KB, text/plain)
2009-12-01 14:37 UTC, Alex Tucker
no flags Details
Xorg log after booting with nomodeset, also through suspend/resume cycle. (72.16 KB, text/plain)
2009-12-01 22:46 UTC, Alex Tucker
no flags 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 (71.05 KB, text/plain)
2009-12-02 10:49 UTC, Alex Tucker
no flags Details
dmesg with drm.debug=1, from after suspend, kernel 2.6.31.6-159.fc12.x86_64, spurious drm_ioctl filtered out (14.60 KB, text/plain)
2009-12-02 10:51 UTC, Alex Tucker
no flags 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 (88.03 KB, text/plain)
2009-12-03 12:27 UTC, Alex Tucker
no flags Details
Phone video of display corruption during and after boot (379.56 KB, video/3gpp)
2009-12-03 12:33 UTC, Alex Tucker
no flags Details
pm-suspend.log (4.08 KB, text/plain)
2009-12-31 20:19 UTC, Hicham HAOUARI
no flags Details
dmesg (34.57 KB, text/plain)
2009-12-31 22:09 UTC, Hicham HAOUARI
no flags Details
spec file to use for the build (112.39 KB, text/x-rpm-spec)
2009-12-31 23:15 UTC, Hicham HAOUARI
no flags Details

Description Alex Tucker 2009-11-26 11:06:16 UTC
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.253.0 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.

Reproducible: Always

Steps to Reproduce:
1. Suspend to ram, e.g. sudo pm-suspend.
2. Wake system, e.g. pressing a key
Actual Results:  
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.

Expected Results:  
Normal display.

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.

Comment 1 Alex Tucker 2009-11-26 11:11:09 UTC
Created attachment 373961 [details]
Xorg.0.log before suspend/resume

Comment 2 Alex Tucker 2009-11-26 11:13:25 UTC
Created attachment 373964 [details]
smolt profile for Ferrari 4005 laptop

Comment 3 Alex Tucker 2009-11-26 11:15:04 UTC
Created attachment 373965 [details]
copy of /var/log/dmesg (with drm.debug=1 on kernel commandline)

Comment 4 Alex Tucker 2009-11-26 11:17:57 UTC
Created attachment 373968 [details]
copy of /var/log/messages from boot, with drm.debug=1, before suspend/resume

Comment 5 Alex Tucker 2009-11-26 11:31:31 UTC
Created attachment 373972 [details]
Photo of screen after resume.

Static photo obviously doesn't show the shaky horizontal fuzzing.

Comment 6 Alex Tucker 2009-11-26 11:33:35 UTC
Created attachment 373973 [details]
Copy of /var/log/messsages after resume, snipped to remove previous logs

Comment 7 Alex Tucker 2009-11-26 11:35:26 UTC
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 :(

Comment 8 Alex Tucker 2009-11-26 11:36:27 UTC
Created attachment 373975 [details]
Xorg.0.log after suspend/resume

Comment 9 Alex Tucker 2009-11-26 11:37:34 UTC
Created attachment 373977 [details]
Output from "radeontool regs" from before suspend/resume

Comment 10 Alex Tucker 2009-11-26 11:38:05 UTC
Created attachment 373978 [details]
Output from "radeontool regs" after suspend/resume

Comment 11 Jérôme Glisse 2009-11-26 15:37:11 UTC
Please capture log with drm.debug=1 most of the time debug is printing useless stuff.

Comment 12 Alex Tucker 2009-11-26 17:14:31 UTC
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.

Comment 13 Alex Tucker 2009-11-30 10:47:23 UTC
Updated to xorg-x11-drv-ati-6.13.0-0.11.20091119git437113124.fc12.x86_64 but no difference.

Comment 14 Dave Airlie 2009-12-01 00:11:42 UTC
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.

Comment 15 Alex Tucker 2009-12-01 12:55:00 UTC
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.

Comment 16 Alex Tucker 2009-12-01 13:14:56 UTC
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.

Comment 17 Alex Tucker 2009-12-01 13:17:15 UTC
Created attachment 375054 [details]
Output from "radeontool regs" from before suspend/resume, kernel 2.6.31.6-157.fc12.x86_64

Comment 18 Alex Tucker 2009-12-01 13:18:52 UTC
Created attachment 375055 [details]
Output from "radeontool regs" after suspend/resume, kernel 2.6.31.6-157.fc12.x86_64

Comment 19 Alex Tucker 2009-12-01 13:40:26 UTC
Created attachment 375063 [details]
/var/log/messages, from boot to just before suspend, kernel 2.6.31.6-157.fc12.x86_64

Comment 20 Alex Tucker 2009-12-01 13:41:54 UTC
Created attachment 375065 [details]
/var/log/messages, from just after suspend, kernel 2.6.31.6-157.fc12.x86_64

Comment 21 Alex Tucker 2009-12-01 14:35:18 UTC
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

Comment 22 Alex Tucker 2009-12-01 14:37:43 UTC
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

Comment 23 Dave Airlie 2009-12-01 22:26:39 UTC
could to boot with nomodeset and attach the /var/log/Xorg.0.log?

Comment 24 Alex Tucker 2009-12-01 22:46:01 UTC
Created attachment 375227 [details]
Xorg log after booting with nomodeset, also through suspend/resume cycle.

Comment 25 Dave Airlie 2009-12-02 06:01:21 UTC
okay we spotted a bug that might explain this, I'll try and build a kernel with it tomorrow or later today.

Comment 26 Dave Airlie 2009-12-02 07:48:54 UTC
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.

Comment 27 Alex Tucker 2009-12-02 10:49:32 UTC
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

Comment 28 Alex Tucker 2009-12-02 10:51:17 UTC
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]).

Comment 29 Dave Airlie 2009-12-02 23:03:32 UTC
okay another attempt at a fix  is about to start building koji in 2.6.31.6-161

let me know how it goes.

Comment 30 Alex Tucker 2009-12-03 12:27:58 UTC
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.

Comment 31 Alex Tucker 2009-12-03 12:33:56 UTC
Created attachment 375755 [details]
Phone video of display corruption during and after boot

Comment 32 Dave Airlie 2009-12-04 21:22:03 UTC
Okay I'll try and get another patch out next week, we at least are very close to narrowing it down.

Comment 33 Mark Chandler 2009-12-07 12:30:38 UTC
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!

Comment 34 Mark Chandler 2009-12-07 13:46:00 UTC
Correction: I'm using the kernel-PAE-2.6.31.6-162.fc12.i686 package.

Comment 35 Matěj Cepl 2009-12-17 00:22:57 UTC
*** Bug 546862 has been marked as a duplicate of this bug. ***

Comment 36 Hicham HAOUARI 2009-12-17 15:20:29 UTC
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

Comment 37 Hicham HAOUARI 2009-12-17 15:26:53 UTC
The corruption i have is the same as :

https://bugzilla.redhat.com/attachment.cgi?id=377859

Comment 38 Dave Airlie 2009-12-21 04:50:55 UTC
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.

Comment 39 Dave Airlie 2009-12-21 05:45:24 UTC
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.

Comment 40 Hicham HAOUARI 2009-12-21 17:21:08 UTC
always a corrupted display upon boot with this kernel+libdrm

plus, X server hangs

Comment 41 Alex Tucker 2009-12-29 20:15:34 UTC
(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.

Comment 42 Hicham HAOUARI 2009-12-31 20:18:15 UTC
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

Comment 43 Hicham HAOUARI 2009-12-31 20:19:21 UTC
Created attachment 381111 [details]
pm-suspend.log

Comment 44 Hicham HAOUARI 2009-12-31 22:09:26 UTC
Created attachment 381120 [details]
dmesg

Comment 45 Hicham HAOUARI 2009-12-31 23:15:00 UTC
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@cvs.fedoraproject.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>

Comment 46 Hicham HAOUARI 2009-12-31 23:15:43 UTC
Created attachment 381126 [details]
spec file to use for the build

Comment 47 Hicham HAOUARI 2010-01-03 19:43:04 UTC
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

Comment 48 Daniel Qarras 2010-01-10 10:51:26 UTC
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.

Comment 49 Hicham HAOUARI 2010-01-10 18:02:12 UTC
@Daniel

did u use any pm-hibernate quirks ?

Comment 50 Hicham HAOUARI 2010-01-10 18:06:11 UTC
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

Comment 51 Daniel Qarras 2010-01-11 07:24:14 UTC
> 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.

Comment 52 Dave Airlie 2010-01-14 08:43:10 UTC
please try 2.6.32.3-24, it should fix failure to suspend (not resume ;-)

Comment 53 the.hw.group 2010-02-04 00:25:16 UTC
this still affects me in both fedora 11, latest updates as of 02.03.2010, as well as on Fedora 12  (32bit)

Comment 54 Daniel Qarras 2010-04-21 17:21:44 UTC
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

Comment 55 Alex Tucker 2010-05-18 14:15:23 UTC
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...

Comment 56 Hicham HAOUARI 2010-09-03 04:23:20 UTC
I am having the same artifacts after resume as comment 16 with latest Fedora 14 i686.

Comment 57 Bug Zapper 2010-11-04 05:16:51 UTC
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

Comment 58 Hicham HAOUARI 2010-11-04 20:25:10 UTC
still exists on rawhide

Comment 59 Daniel Qarras 2011-06-18 09:45:54 UTC
FWIW, I filed Bug 710243 for Fedora 15 with complete set of logs - suspend works but resume fails as described here.

Comment 60 Fedora End Of Life 2013-04-03 20:05:32 UTC
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

Comment 61 dennisn 2013-05-02 23:39:36 UTC
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.)

Comment 62 dennisn 2013-05-03 15:35:34 UTC
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.)

Comment 63 Alex Tucker 2014-06-23 11:44:37 UTC
As per comment 55, I can no longer help with this bug, so I'm closing.


Note You need to log in before you can comment on or make changes to this bug.