Description of Problem:
See also bug 62171. When I suspend/resume my laptop, the X server locks up
after resume leaving the display unusable. The machine is still up and
accessible from the network, but the only way I can find to get the display back
is to reboot. My apm configuration is such that we switch VCs away from X
before suspend and back after resume. I am running a version of the X server
that includes the radeon fix from bug 62171, and switching virtual consoles
while running works just fine now. As with the other bug, commenting out the
line from XF86Config that loads "dri" works around the problem; i.e., without
dri, I can suspend (to disk) and resume without incident. (The laptop never
comes out of suspend to RAM properly under Linux in or not in X, but that's
another issue for another day.)
Version-Release number of selected component (if applicable):
XFree86-4.2.0-57.1 (limbo + up2date)
Steps to Reproduce:
1. Get my laptop with my configuration. :-/
2. Suspend to disk with Fn-F12
The X server locks up in the same manner is it used to with a VC switch
It shouldn't lock up.
I realize that these types of laptop problems are problematic and hard to fix,
especially when suspend/resume are involved, but since this is so similar to
another problem that was successfully fixed, I thought it was worth reporting.
This problem happens with limbo + up2date, but it also happened under RedHat
7.3. My laptop has a pretty normal configuration -- Limbo/Valhalla pretty much
out of the box. The problem happens with the default apm configuration, but it
did not go away when I changed my configuration to switch away from and back to
X. This change is required to get everything to work without dri.
I'm attaching the output of lspci -vvn, which is unchanged before and after a
suspend/resume cycle. I'm also attaching my XF86-config file and my
If there's anything else I should try, please let me know.
Created attachment 70064 [details]
my XF86Config file
Created attachment 70065 [details]
My /etc/sysconfig/apmd file
Created attachment 70066 [details]
output of lspci -vvn which is identical before and after suspend/resume
APM related problems lately seem to be caused by XFree86 resuming before
the apm scripts complete. Try switching to a VC first before suspending,
and then resuming, then switching back to XFree86.
Does that work?
It doesn't work. I actually mentioned under "Additional Information" above that
I have my apm configuration set to switch VTs away from X and back and that this
is required to make things work without DRI. Just to be sure, though, I turned
this off in /etc/sysconfig/apmd and manually switched VTs before suspending.
After resuming, the system worked fine. As soon as I switched back to X though
the display locked up. This is unsurprising behavior given what the CHANGEVT
code in the apm scripts do. I do understand, however, that using CHANGEVT
causes chvt to be run before the apm scripts finish because it is run inside of
the apm scripts, so I do not mean to imply that the suggestion was vacuuous.
Please read bug #63509 and try the packages suggested there as well to
see if they fix this problem for you.
Do the new packages resolve this?
I think this is related to the radeon dri module not being able to handle
suspend/resume at all. I saw some mention on the xfree mailing list that the
patch found here:
Quoting from this guy's weblog:
dri_resume for XFree86 4.3.0 RC 1
I've made binary snapshots of my suspend/resume capable DRI Radeon drivers for
XFree86 4.3.0 RC 1 (i.e. 18.104.22.1681) available on the dri resume pages.
My patches weren't submitted early enough to be included in the looming XFree86
4.3.0 release, but will be merged with the XFree86 CVS shortly afterwards. Once
more distribution vendors have standardised on 4.3.0 and things have settled
down, my binary drivers should also be able to stabilise.
I was already using the new packages in bug 63509. They solved the VC switching
problem but not the suspend problem. I can also confirm that this is still a
problem in phoebe2 + up2date (as of 2/11/03). I guess we'll just have to wait
for the fix mentioned above to make it into the release. Should this now be
changed back to ASSIGNED?
Oh well, I guess the fix didn't make it into RHL9, but I believe that was
expected. Hopefully the next release will have a version of XFree86 that
includes this patch.
Just in case the XFree86 4.3.0 in RHL9 does include the patch discussed above
(though the changelog makes no mention of this), I will report that I see this
same behavior with RHL9 on my laptop.
This patch is not in Red Hat Linux 9, and I have no plans of including it
in any future release.
Defering issue until a less intrusive solution is available.
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue. Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:
If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.
Setting status to "CURRENTRELEASE".