hi, My system: IBM Laptop T40 2373-8cg Debian Linux Sid Kernel 2.6.8.1 + 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): http://fallenangel.deathcon.de/xorg.log http://fallenangel.deathcon.de/dmesg.log Is there a newer cvs code or how can I help to fix this problem. Greetz Konstantin
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...
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.