Created attachment 36970 [details]
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.
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)
Is your distro using any vbetool pm quirks? If so, disable them.
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.
Created attachment 36985 [details]
/var/log/message with drm.debug=15
(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.
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
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:
Picture of framebuffer after suspend:
Created attachment 36997 [details]
drm.debug=15 on HD3870, x86_64
If s/r used to work, when did it last work, and can you bisect what commit broke it?
(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).
Still an issue with recent kernel ?
(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.
(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
radeonreg regs all > fixed.regs
Created attachment 43235 [details]
Are you using an analog or digital connection for the monitor?
(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.