Bug 1220

Do you switch to console for suspend? You need to do that as your system doesn't
seem to support APM.

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.

Greetz

Konstantin

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.

hi,

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?

Greetz

Konstantin

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

Dominik

hi,

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

#!/bin/sh

#
# IT'S NOT A SOLUTION, BUT ONLY A WORK AROUND FOR
# THE DRI FAULT. FOR USERS WITH A GARBAGE SCREEN
# AFTER RESUME AND ESPECIALLY THOSE WITH ACPI.
# WORKS FOR RADEON AND NVIDIA USERS!!!!
#
# RELEASED UNDER GPL License 2 and later ....


# Software-Suspend 2 script
# Or where ever your hibernate script
# or command is.
/usr/local/sbin/hibernate

# 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!

Greetz

Konstantin Filtschew

I have a similar issue with a Radeon Mobility 9000 M9 and pmdisk and kernel
2.6.8.1 (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.

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

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. 

hi,

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 @@
     }
 #endif
  
+#if 0
     RADEONSetFBLocation(pScrn);
+#endif
  
     if (!fbScreenInit(pScreen, info->FB,
                      pScrn->virtualX, pScrn->virtualY,

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

Best wishes,
-- 
fabrice


----- 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!

Ah, I'm using radeonfb if that matters, I'll try without later on. 

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. 

... 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 
  necessary 
 
This is a prerequisite for things like direct rendering with IGP chips and 
video capturing. 
 
Maybe he can help here? 

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.

hi,

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:
http://fallenangel.deathcon.de/xorg.log

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.

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.

Looks good to me.

On second thought, the RADEONSetFBLocation() call should be moved before the
#ifdef XF86DRI check.

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

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

If you close the bug as FIXED it indicates that the fix is already in CVS. Is it?

not in CVS yet, have to wait, till it's done

*** Bug 1398 has been marked as a duplicate of this bug. ***

*** Bug 1591 has been marked as a duplicate of this bug. ***

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.

The patch is still not commited to CVS. Therefore this bugreport is still 
open. 

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: 
      [...] 
      xc/programs/Xserver/hw/xfree86/drivers/ati/: 
        radeon_driver.c 
      [...] 
Revision  Changes  Path 
[...] 
1.23        +1 -0  xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 
[...] 
 

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.

(In reply to comment #28)

I think it's XORG-6_8-branch.

committed to XORG-6_8-branch as well.

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 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 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	<-- 
radeon_driver.c
new revision: 1.19.2.7; previous revision: 1.19.2.6
/cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h,v  <-- 
radeon_reg.h
new revision: 1.7.2.1; 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...