Bug 29026 - [RADEON:KMS:RV670:MODESET] garbled screen after resuming from suspend
Summary: [RADEON:KMS:RV670:MODESET] garbled screen after resuming from suspend
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-12 13:05 UTC by Daniel Klaffenbach
Modified: 2011-02-14 00:50 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
system log (46.36 KB, text/plain)
2010-07-12 13:05 UTC, Daniel Klaffenbach
no flags Details
/var/log/message with drm.debug=15 (60.00 KB, application/octet-stream)
2010-07-12 22:04 UTC, Alexandre Derumier
no flags Details
drm.debug=15 on HD3870, x86_64 (220.18 KB, text/plain)
2010-07-13 11:41 UTC, Daniel Klaffenbach
no flags Details
register dump (12.45 KB, application/x-bzip)
2011-02-11 00:16 UTC, Daniel Klaffenbach
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Klaffenbach 2010-07-12 13:05:52 UTC
Created attachment 36970 [details]
system log

Using mesa-git, libdrm-git and xf86-video-ati-git I always get a garbled screen (including framebuffer console) after resume. I took a screenshot, but obviously it looks normal.

Video card: Radeon HD3870
Kernel: Linux-git (2.6.35-rc4+), KMS enabled by default

There is no crash or lockup, it's just sort of impossible to read anything on the screen after resuming.
Comment 1 Jerome Glisse 2010-07-12 13:11:55 UTC
Can you take picture of the screen (no need for high res pic, just something good enough so we can see the issue). Also could you boot and suspend with drm.debug=15 option and attach system log with that option (after suspend/resume cycle)
Comment 2 Alex Deucher 2010-07-12 13:40:07 UTC
Is your distro using any vbetool pm quirks?  If so, disable them.
Comment 3 Alexandre Derumier 2010-07-12 22:03:53 UTC
same problem for me, with last drm-radeon-testing kernel on a rv620 (dell studio 15 laptop).

I'm using archlinux, with last mesa-git, ati-git,libdrm-git.
Comment 4 Alexandre Derumier 2010-07-12 22:04:47 UTC
Created attachment 36985 [details]
/var/log/message with drm.debug=15
Comment 5 Rafał Miłecki 2010-07-12 23:03:56 UTC
(In reply to comment #3)
> same problem for me, with last drm-radeon-testing kernel on a rv620 (dell
> studio 15 laptop).
> 
> I'm using archlinux, with last mesa-git, ati-git,libdrm-git.

What about pm-utils? Do you use it? If so, try version 1.3.0 which recognizes KMS.
Comment 6 Alexandre Derumier 2010-07-13 04:43:38 UTC
i'm using pm-utils 1.4 (no problem with drm-radeon-testing around 20 june)

i'll try to dig around pm-utils, i see they are many video quirks in

usr/lib/pm-utils/video-quirks/
Comment 7 Daniel Klaffenbach 2010-07-13 11:38:14 UTC
I am using pm-utils 1.4.1 and all of the video quirks are disabled on my machine.

Picture of X-Server after suspend:
http://yfrog.com/5m20100713001j

Picture of framebuffer after suspend:
http://yfrog.com/4v20100713003j
Comment 8 Daniel Klaffenbach 2010-07-13 11:41:04 UTC
Created attachment 36997 [details]
drm.debug=15 on HD3870, x86_64
Comment 9 Alex Deucher 2010-07-13 12:23:09 UTC
If s/r used to work, when did it last work, and can you bisect what commit broke it?
Comment 10 Daniel Klaffenbach 2010-10-12 15:45:01 UTC
(In reply to comment #9)
> If s/r used to work, when did it last work, and can you bisect what commit
> broke it?
Sorry for the late reply. I cannot find the commit which broke it, however this is still an issue.

I figured out that using xrandr after resuming fixes the garbled screen (setting a different resolution and restoring the original one afterwards).
Comment 11 Jerome Glisse 2011-02-09 07:20:48 UTC
Still an issue with recent kernel ?
Comment 12 Daniel Klaffenbach 2011-02-10 02:02:36 UTC
(In reply to comment #11)
> Still an issue with recent kernel ?
Yes. The exact same thing is still happening to me on 2.6.38-rc4 and xf86-video-ati git.

As I already mentioned the garbled screen issue goes away when using xrandr after resume. I personally fixed this for me by executing the following *dirty* quirk-script on resume:

> export DISPLAY=:0
> export XAUTHORITY="/home/$USER/.Xauthority"
> xrandr --output DVI-0 --mode 1920x1080
> xrandr --output DVI-0 --mode 1680x1050


But obviously this cannot be a permanent solution.
Comment 13 Alex Deucher 2011-02-10 08:50:04 UTC
(In reply to comment #12)
> As I already mentioned the garbled screen issue goes away when using xrandr
> after resume. I personally fixed this for me by executing the following *dirty*
> quirk-script on resume:
>

Can you dump your regs before and after calling xrandr? using radeonreg available here (http://cgit.freedesktop.org/~airlied/radeontool/)

(as root after resume):
radeonreg regs all > broken.regs
(run xrandr)
radeonreg regs all > fixed.regs
Comment 14 Daniel Klaffenbach 2011-02-11 00:16:34 UTC
Created attachment 43235 [details]
register dump
Comment 15 Alex Deucher 2011-02-13 22:44:51 UTC
Are you using an analog or digital connection for the monitor?
Comment 16 Daniel Klaffenbach 2011-02-14 00:50:44 UTC
(In reply to comment #15)
> Are you using an analog or digital connection for the monitor?
I am only using digital connections.

The card has three ports:
DVI-0: My primary monitor (through DVI)
DVI-1: My AV receiver (using the DVI2HDMI adaptor that came with the card), usually turned off
DIN: Not used (radeon.tv=0).


And I just noticed a very interesting thing:
The TV connected to my AV receiver (DVI-1) works just fine after resuming - only the primary screen on DVI-0 is garbled.


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.