Bug 71348 - X server locks up after suspend/resume on HP Omnibook 6100 w/ Radeon Mobility M6
Summary: X server locks up after suspend/resume on HP Omnibook 6100 w/ Radeon Mobility M6
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 82776
TreeView+ depends on / blocked
Reported: 2002-08-12 15:52 UTC by Jay Berkenbilt
Modified: 2007-04-18 16:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-20 14:50:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
my XF86Config file (3.27 KB, text/plain)
2002-08-12 15:53 UTC, Jay Berkenbilt
no flags Details
My /etc/sysconfig/apmd file (4.47 KB, text/plain)
2002-08-12 15:53 UTC, Jay Berkenbilt
no flags Details
output of lspci -vvn which is identical before and after suspend/resume (6.58 KB, text/plain)
2002-08-12 15:54 UTC, Jay Berkenbilt
no flags Details

Description Jay Berkenbilt 2002-08-12 15:52:14 UTC
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)

How Reproducible:


Steps to Reproduce:
1. Get my laptop with my configuration. :-/
2. Suspend to disk with Fn-F12
3. Resume

Actual Results:

The X server locks up in the same manner is it used to with a VC switch

Expected Results:

It shouldn't lock up.

Additional Information:
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
/etc/sysconfig/apmd file.

If there's anything else I should try, please let me know.

Comment 1 Jay Berkenbilt 2002-08-12 15:53:06 UTC
Created attachment 70064 [details]
my XF86Config file

Comment 2 Jay Berkenbilt 2002-08-12 15:53:41 UTC
Created attachment 70065 [details]
My /etc/sysconfig/apmd file

Comment 3 Jay Berkenbilt 2002-08-12 15:54:17 UTC
Created attachment 70066 [details]
output of lspci -vvn which is identical before and after suspend/resume

Comment 4 Mike A. Harris 2002-08-13 03:18:11 UTC
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?

Comment 5 Jay Berkenbilt 2002-08-13 21:12:55 UTC
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.

Comment 6 Mike A. Harris 2002-12-22 09:02:29 UTC
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?

Comment 7 Kjartan Maraas 2003-02-10 14:52:13 UTC
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. 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.

Comment 8 Jay Berkenbilt 2003-02-12 03:11:46 UTC
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?

Comment 9 Jay Berkenbilt 2003-04-05 23:05:28 UTC
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.

Comment 10 Mike A. Harris 2003-04-06 02:01:07 UTC
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.

Comment 11 Mike A. Harris 2005-04-20 14:50:45 UTC
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".

Note You need to log in before you can comment on or make changes to this bug.