Bug 1220 - Garbage screen after resume from suspend to disk
Summary: Garbage screen after resume from suspend to disk
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/other (show other bugs)
Version: XOrg git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Default DRI bug account
QA Contact:
: 1398 1591 (view as bug list)
Depends on:
Blocks: 269
  Show dependency treegraph
Reported: 2004-08-28 05:15 UTC by Konstantin Filtschew
Modified: 2009-04-03 01:22 UTC (History)
10 users (show)

See Also:
i915 platform:
i915 features:

This one-liner fixes suspend to disk. (757 bytes, patch)
2004-09-28 09:31 UTC, Matthias Hopf
no flags Details | Splinter Review
[FIXED_X11R68x] Updated fix (785 bytes, patch)
2004-09-29 01:15 UTC, Matthias Hopf
roland.mainz: 6.8-branch+
Details | Splinter Review

Description Konstantin Filtschew 2004-08-28 05:15:57 UTC

My system: IBM Laptop T40 2373-8cg
Debian Linux Sid
Kernel + acpi patch
ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]
Xorg.CVS from 2004-08-27 6pm middle european time

I've tried to setup suspend-to-disk with:
pmdisk, swsusp and swups2
but get always a garbage screen after resume, if dri module is loaded.

here are some logs(in both  nothing special):

Is there a newer cvs code or  how can I help to fix this problem.


Comment 1 Michel Dänzer 2004-08-28 10:00:55 UTC
Do you switch to console for suspend? You need to do that as your system doesn't
seem to support APM.
Comment 2 Konstantin Filtschew 2004-08-29 02:51:11 UTC
My system supports apm, but thats not a solution, it's a step back.

I used Xfree86 4.3 from Debian before and it works fine. But
I need X.org for Powermanagement of my Radeon. IBM has a known
fan problem, because the radeon chip gets too hot without
dynamic clocking

I use a workaround now:
xinit /bin/false -- :1 &
This starts a fake X sessions and after waiting about 10 sec,
the screen turns to normal.

As I know, that it worked before, I think there must be a bug
in the source.

APM was never a solution for notebooks, because it wastes too
much power.

Tell me, how I can help to fix this.


Comment 3 Michel Dänzer 2004-09-05 18:22:11 UTC
The only way for the X server to react to the suspend/resume is via APM (which
basically emulates a VT switch) or via a VT switch. If it worked for you with
neither before, you either didn't have the DRI enabled or got lucky.
Comment 4 Konstantin Filtschew 2004-09-06 00:38:55 UTC

the dri module was enabled. I have and had 700+Fps in glxgears

It works for X.org 7.6.rc2 and Xfree86 4.3 too, so it's not an
direct X.org problem. But I need the power management of the CVS
version, which rise my laptop work in accu mode a half hour longer!

I know that it worked with the old DRI version on several laptops,
so I think it can be fixed in code. Is there a chance to add the
acpi support to dri/x.org, so it'll work on all ACPI Systems?


Comment 5 melan 2004-09-10 05:59:47 UTC
I have a similar problem: I have a Sony Vaio PCR-Z1RMP with ATI Radeon Mobility 
M6 and I'm using the radeon driver.

I use kernel with software suspend 2 (softwaresuspend.berlios.de), which 
works without problems with xorg 6.7 (and XFree86 4.3) on gentoo.

Yesterday I tested the new xorg 6.8 and I also got a garbage screen after 
suspend and resume. If I switch to console before suspend, the console is ok 
after resume, but if I switch back to X then, it is the same garbage, if I then 
switch back to the console there is also garbage.

So I think it has to do with the changes in the radeon driver from 6.7 to 6.8. 
Maybe the new driver depends on something that is "stored" on the card and that 
is gone after the suspend resume cycle (reboot).

I downgraded to 6.7 and everything works again.

I already contacted the developer of software suspend 2, Nigel Cunningham 
(ncunningham@linuxmail.org), he couldn't help me, but he suggested that you 
maybe could contact him and then you could work together.

Comment 6 Konstantin Filtschew 2004-09-10 07:09:24 UTC

I've talked to Cunningham and we came to the conclusion, that this is
a dri fault.

It's not a fault, but a missing implementation of resume with acpi.
(This was told to me by the dri developers.)
This should work fine with APM, which is not a solution for me!

You can try to install X.org 6.8 and remove the dri support.
After that it'll work fine.

I use an other solution, which works with acpi and dri, 
but need 5 sec more to resume from Suspend to Disk:
I start after suspend a Fake Xsession, which reloads the dri driver and
everything works fine.

Because of the Xsession this script can not be run by a key
combination, but this must be only a output fault of
the fake Xsession command, which must be fixed(have no time
to care about).

You can try this script:

---------------CUT HERE ------------------


# RELEASED UNDER GPL License 2 and later ....

# Software-Suspend 2 script
# Or where ever your hibernate script
# or command is.

# Use this, if you don't have 
# Software Suspend 2, but only
# the integretad software-suspend
# from Kernel
# echo -n 4 > /proc/acpi/sleep

# Or this,which depends on your kernel config
# For pmdisk(Suspend to disk called) mode
# echo -n disk > /sys/power/state

# Only on some systems need, try to run the
# fake Xsession command without suspend 
# stuff as User root.
# Gentoo Users will need this!
export PATH=/usr/X11R6/bin:"${PATH}"  

# Starts a fake Xsession and abort it afterwards
# The dri fault in the radeon driver need this,
# to remove the garbage screen after resume from
# Suspend to Disk
/usr/bin/X11/xinit /bin/false -- :1 &  

exit 0

----------------- CUT HERE --------------------

Suspend to RAM works fine without!


Konstantin Filtschew
Comment 7 Jukka Ketelaars 2004-09-12 13:18:23 UTC
I have a similar issue with a Radeon Mobility 9000 M9 and pmdisk and kernel (and 2.6.9-rc1) utilizing ACPI on a HP nx7010. I do not get garbage
after resume, the screen looks fine, but DRI is turned off (glxinfo confirms
this). The trick of starting another X session, that Konstantin mentioned (BTW,
thanks for that), also works for me. After the session has started, the session
that was open during suspend, has DRI turned back on.
Comment 8 Fabrice Bellet 2004-09-14 13:45:05 UTC
I have a T40, with a radeon mobility M9, and I also experienced garbled screen
when resuming from acpi S4 (aka suspend to disk). Acpi S3 works fine, and APM is
okay too. Only resume from acpi S4 fails. A workaround to this problem, that
works for me, is to _not_ call RADEONSetFBLocation(pScrn) in RADEONScreenInit().
Comment 9 Karol Kozimor 2004-09-21 00:25:22 UTC
It seems this is a regression over 6.7. The VT switch doesn't POST the chip as 
expected. Furthermore, my M7 just hangs if I launch a second X session. 
Comment 10 Konstantin Filtschew 2004-09-21 02:26:56 UTC

you have to start it in background or it won't work, but there is a code fix,
which is maybe or hopefully implemented i CVS.

this was send to me by  Fabrice Bellet, which works for me too:

----- E-Mail from Fabrice Bellet --------------------------

I use xorg CVS, so I patched the file :
xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c and I recompiled the 
driver radeon_drv.o in this directory.

Index: radeon_driver.c
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.19
diff -u -r1.19 radeon_driver.c
--- radeon_driver.c     25 Aug 2004 00:30:41 -0000      1.19
+++ radeon_driver.c     16 Sep 2004 10:51:23 -0000
@@ -4562,7 +4562,9 @@
+#if 0
     if (!fbScreenInit(pScreen, info->FB,
                      pScrn->virtualX, pScrn->virtualY,

But I'm not sure at all, that this is the correct fix. 

Best wishes,

----- E-Mail from Fabrice Bellet --------------------------

thx to Fabrice for the fix, it's the right one!!!!

I hope some developer implement this in the CVS tree, if it's not
done yet!
Comment 11 Karol Kozimor 2004-09-21 03:40:37 UTC
Ah, I'm using radeonfb if that matters, I'll try without later on. 
Comment 12 Stefan Dirsch 2004-09-27 20:23:14 UTC
The new function RADEONSetFBLocation and the call for it came in with  
revision 1.3 
date: 2004-06-16 09:43:59 +0000; author: anholt;  state: Exp; lines: +811 -505 
Merge DRI-trunk-20040613 changes in programs/Xserver/hw/xfree86/drivers 
Maybe Eric can comment on this. 
Comment 13 Stefan Dirsch 2004-09-27 20:44:31 UTC
... which initially was introduced by Michel Daenzer in DRI CVS: 
revision 1.78 
date: 2003-11-04 00:46:05 +0000;  author: daenzer;  state: Exp; lines: +66 -25 
Memory layout transition: 
* the 2D driver initializes MC_FB_LOCATION and related registers sanely 
* the DRM deduces the layout from these registers 
* clients use the new SETPARAM ioctl to tell the DRM where they think the 
  framebuffer is located in the card's address space 
* the DRM uses all this information to check client state and fix it up if 
This is a prerequisite for things like direct rendering with IGP chips and 
video capturing. 
Maybe he can help here? 
Comment 14 Michel Dänzer 2004-09-27 21:09:18 UTC
As should be obvious from my commit log, the RADEONSetFBLocation() call can't
just  be removed. What might work instead is calling it in EnterVT() as well
(beware that it might cause trouble in the wrong place). Ideally, the contents
of those registers should also be restored when VT switching away from the
server and shutting down.
Comment 15 Konstantin Filtschew 2004-09-28 03:13:27 UTC

the problem for me is very simple, I need acpi and suspend to disk.

The workaround is a bad solution, but commenting out the line works for me,
because I can use suspend and everything else works fine.

The log, here you can see it for yourself:

The log is from 4 days Uptime and I used 5 or more times Suspend to Disk.

If there is a better solution or any chance I can help to fix this,
just tell me. I would try patches, this shouldn't be a problem.
Comment 16 Matthias Hopf 2004-09-28 09:31:11 UTC
Created attachment 975 [details] [review]
This one-liner fixes suspend to disk.

This one-liner fixes suspend to disk. Even works with 3D apps running. Please
check and post whether there are any problems with this patch.
Comment 17 Michel Dänzer 2004-09-28 16:57:01 UTC
Looks good to me.
Comment 18 Michel Dänzer 2004-09-28 16:59:39 UTC
On second thought, the RADEONSetFBLocation() call should be moved before the
#ifdef XF86DRI check.
Comment 19 Matthias Hopf 2004-09-29 01:15:28 UTC
Created attachment 980 [details] [review]
[FIXED_X11R68x] Updated fix

After reading a line or two of code I suspect that you are right. Didn't
include it before the #ifdef XF86DRI, because the bug only showed up w/ dri
Comment 20 Konstantin Filtschew 2004-09-29 02:51:05 UTC
thx for help,

the patch works fine 

this is the right fix:
} else
 	if (!RADEONModeInit(pScrn, pScrn->currentMode)) return FALSE;
+    RADEONSetFBLocation (pScrn);
 #ifdef XF86DRI
     if (info->directRenderingEnabled) {
 	/* get the Radeon back into shape after resume */

thx for your help, I hope it'll be included in the next release
Comment 21 Henrik Brix Andersen 2004-09-29 02:54:31 UTC
If you close the bug as FIXED it indicates that the fix is already in CVS. Is it?
Comment 22 Konstantin Filtschew 2004-09-29 03:03:44 UTC
not in CVS yet, have to wait, till it's done
Comment 23 Giridhar Pemmasani 2004-09-29 03:49:28 UTC
*** Bug 1398 has been marked as a duplicate of this bug. ***
Comment 24 Stefan Dirsch 2004-10-11 13:05:31 UTC
*** Bug 1591 has been marked as a duplicate of this bug. ***
Comment 25 Konstantin Filtschew 2004-10-11 13:39:33 UTC
can anyone of the developer confirm me, that this was patched in CVS, I don't
want to leech the whole CVS tree because of one file.

The web CVS has also a bug, so I can't watch it there.
Comment 26 Stefan Dirsch 2004-10-11 14:04:53 UTC
The patch is still not commited to CVS. Therefore this bugreport is still 
Comment 27 Stefan Dirsch 2004-10-11 17:57:44 UTC
fixed now in CVS. 
CVSROOT:        /cvs/xorg 
Module name:    xc 
Changes by:     agd5f@gabe.     04/10/11 16:20:26 
Log message: 
          - fix resume on radeons (bug 1220) 
Modified files: 
Revision  Changes  Path 
1.23        +1 -0  xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 
Comment 28 Alex Deucher 2004-10-11 21:17:56 UTC
This really ought to be applied to the stable/6.8 branch as well.  I would have
done it myself, but I'm not sure which branch it needs to go on.
Comment 29 Michel Dänzer 2004-10-12 12:33:26 UTC
(In reply to comment #28)

I think it's XORG-6_8-branch.
Comment 30 Alex Deucher 2004-10-17 16:08:21 UTC
committed to XORG-6_8-branch as well.
Comment 31 Roland Mainz 2004-11-12 16:19:47 UTC
Comment on attachment 980 [details] [review]
[FIXED_X11R68x] Updated fix

Erm... why was this patch commited after the final X11R6.8.1 tag was made ?!

Anyway... the patch seems to be very usefull so I am requesting (post-commit)
approval  to get it officially approved for the X11R6.8.x branch...
Comment 32 Roland Mainz 2004-11-19 07:26:39 UTC
Comment on attachment 980 [details] [review]
[FIXED_X11R68x] Updated fix

Approved for X11R6.8.x branch in the 2004-11-17 release-wranglers call (no need
to commit as the patch has already been commited a while ago).
Comment 33 Roland Mainz 2004-12-16 16:14:36 UTC
Comment on attachment 980 [details] [review]
[FIXED_X11R68x] Updated fix

Patch checked-in into Xorg trunk and X11R6.8.x ...

/cvs/xorg/xc/ChangeLog,v  <--  ChangeLog
new revision: 1.365.2.101; previous revision: 1.365.2.100
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
/cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v	<-- 
new revision:; previous revision:
/cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h,v  <-- 
new revision:; previous revision: 1.7
cvs commit: Using deprecated info format strings.  Convert your scripts to use
the new argument format and remove '1's from your info file format strings.
Mailing the commit message to xorg-commit@lists.freedesktop.org...

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.