Bug 29217 - After pm-suspend the second monitor shows garbled output on evergreen card (kms)
Summary: After pm-suspend the second monitor shows garbled output on evergreen card (kms)
Status: RESOLVED MOVED
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-22 08:30 UTC by boris64
Modified: 2019-11-19 08:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
digicam picture of both monitors (146.25 KB, image/jpeg)
2010-07-22 08:30 UTC, boris64
no flags Details
lspci -vv (32.58 KB, text/plain)
2010-07-22 08:31 UTC, boris64
no flags Details
dmesg (30.33 KB, text/plain)
2010-07-22 08:31 UTC, boris64
no flags Details
Xorg.0.log (131.30 KB, patch)
2010-07-22 08:32 UTC, boris64
no flags Details | Splinter Review
xrandr --verbose (9.29 KB, text/plain)
2010-07-22 08:32 UTC, boris64
no flags Details
digicam picture of console after resume and vt switch (212.90 KB, image/jpeg)
2010-07-22 09:45 UTC, boris64
no flags Details

Description boris64 2010-07-22 08:30:41 UTC
Created attachment 37311 [details]
digicam picture of both monitors

After resuming a previous (via pm-suspend) suspended system 
the second monitor only shows a garbled picture.
Running xrandr to switch resolution seems to work, but
the picture still ist truncated.
This is a kms/multihead configuration.

Used software:
  Kernel-2.6.35-rc5
  latest xf86-video-ati from git
  latest libdrm from git
  latest mesa from git
Comment 1 boris64 2010-07-22 08:31:37 UTC
Created attachment 37312 [details]
lspci -vv
Comment 2 boris64 2010-07-22 08:31:58 UTC
Created attachment 37313 [details]
dmesg
Comment 3 boris64 2010-07-22 08:32:28 UTC
Created attachment 37314 [details] [review]
Xorg.0.log
Comment 4 boris64 2010-07-22 08:32:54 UTC
Created attachment 37315 [details]
xrandr --verbose
Comment 5 Alex Deucher 2010-07-22 08:48:35 UTC
Does the other monitor work properly if you turn it off and then re-enable it with xrandr (e.g., --off, followed by --auto)?
Comment 6 Alex Deucher 2010-07-22 08:49:58 UTC
Does doing a VT switch before suspend help?
Comment 7 boris64 2010-07-22 08:55:48 UTC
No / No.

It even doesn't seem to work after a warm reboot.
I only get a test picture (as if there was no 
connection between monitor and graphic card)
when the bios boots up.

I had to hard reset the computer 
to get a working second monitor again.
Comment 8 Alex Deucher 2010-07-22 08:59:18 UTC
Does the second monitor enable properly if you cold boot without it attached and then attach it after X has started?
Comment 9 boris64 2010-07-22 09:42:54 UTC
Appendix:
If i run 'xrandr --output DVI-1 --off' followed by
'xrandr --output DVI-1 --auto' the second monitor switches off
and then on again (garbled screen).

Now if i run 'xrandr --output DVI-0 --auto' (happend accidentally first time),
monitor one switches to off and the second monitor shows
a correct piture again. Huh?! 
Running 'xrandr --output DVI-0 --auto' afterwards makes
monitor one work and monitor two have a garbled picture again.

Will now try that cold boot thing.
Comment 10 boris64 2010-07-22 09:45:27 UTC
Created attachment 37316 [details]
digicam picture of console after resume and vt switch
Comment 11 boris64 2010-07-22 09:53:09 UTC
(In reply to comment #8)
> Does the second monitor enable properly if you cold boot without it attached
> and then attach it after X has started?

I think Yes.
I have to run 'xrandr --output DVI-1 --auto' to 
get my desktop back, though.
Comment 12 boris64 2010-07-24 05:14:12 UTC
Update:
Enabling "Repost Video On S3 Resume" in BIOS seems
to help a lot. I've send my computer into sleepmode
for a couple of times now and the second monitor has 
always been working fine after resuming.

I actually dunno what this BIOS option does,
but it seems to be a solution.
Comment 13 Martin Peres 2019-11-19 08:14:28 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/144.


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.