[RADEON:KMS:RV670:MODESET] garbled screen after resuming from suspend

Submitted by Daniel Klaffenbach

Assigned to Default DRI bug account

Link to original bug (#29026)

Description

Created attachment 36970
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.

Attachment 36970, "system log":
dmesg.txt

added Radeon bugzilla labels

Jerome Glisse said:

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)

Alex Deucher @agd5f said:

Is your distro using any vbetool pm quirks? If so, disable them.

Alexandre Derumier said:

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.

Alexandre Derumier uploaded an attachment:

Attachment 36985, "/var/log/message with drm.debug=15":
messages.drmdebug15.log

Rafał Miłecki said:

(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.

Alexandre Derumier said:

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/

Daniel Klaffenbach said:

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

Daniel Klaffenbach uploaded an attachment:

Attachment 36997, "drm.debug=15 on HD3870, x86_64":
drm-debug.txt

Alex Deucher @agd5f said:

If s/r used to work, when did it last work, and can you bisect what commit broke it?

Daniel Klaffenbach said:

(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).

Jerome Glisse said:

Still an issue with recent kernel ?

Daniel Klaffenbach said:

(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.

Alex Deucher @agd5f said:

(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

Daniel Klaffenbach uploaded an attachment:

Attachment 43235, "register dump":
regs.tar.bz2

Alex Deucher @agd5f said:

Are you using an analog or digital connection for the monitor?

Daniel Klaffenbach said:

(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.

closed