Bug 71348
| Summary: | X server locks up after suspend/resume on HP Omnibook 6100 w/ Radeon Mobility M6 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Jay Berkenbilt <ejb> | ||||||||
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 8.0 | CC: | ejb | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i386 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2005-04-20 14:50:45 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 82776 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Jay Berkenbilt
2002-08-12 15:52:14 UTC
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: http://cpbotha.net/dri_resume.html 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. 4.2.99.901) 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:
http://fedora.redhat.com/download
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"
component.
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".
|