Bug 494705
| Summary: | X + Intel driver becomes unstable after suspend/resume cycle if the state of an external display is changed | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Hezekiah M. Carty <hez> |
| Component: | xorg-x11-drv-intel | Assignee: | Kristian Høgsberg <krh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | ajax, james, mcepl, misieck, scottt.tw, xgl-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | F11 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-06-23 06:18:44 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: | |||
| Attachments: | |||
|
Description
Hezekiah M. Carty
2009-04-07 20:29:45 UTC
Created attachment 339021 [details]
dmesg output after a X restart
This dmesg output is from about a minute after a resume from a suspend to ram. X restarted immediately after the system resumed - I saw a flash of my open apps and desktop, and then X restarted and the GDM login was back.
Created attachment 339022 [details]
pm-suspend.log after X restart
The pm-suspend.log which goes along with the dmesg output just posted
Created attachment 339023 [details]
Xorg.0.log.old (from the pre-restart X)
The Xorg.0.log.old which goes along with the pre-suspend and very slightly post-suspend session
Created attachment 339024 [details]
Xorg.0.log (from the post-restart X)
The Xorg.0.log from the new (post-restart) X session
Is there any further information I can provide to help with fixing this bug? I would like to confirm for 2.6.29.3-155. For me it mostly exhibits itself as font or image corruption after resume from suspend. It is only some particular (but it appears, randomly chosen) fonts that get corrupted. The other fonts are unaffected. It is easiest to see in firefox on some sites but even the control application for VirtualBox may be heavily affected. It can get bad enough to make it difficult or impossible to understand the text. Some widgets like buttons or drop down list buttons get filled with phantom images that were probably loaded at some time in the past. Font corruption is quite static but widget corruption changes more during use. It happens with or without compiz. I did have some unexplained X restarts. It happened when a lot of memory was used by other programs. My hardware is HP Compa 6510b with 4G ram and core 2 duo. Attaching some images. Created attachment 345365 [details]
A firefox window showing font corruption.
Created attachment 345366 [details]
VirtualBox showing graphical and font corruption
(In reply to comment #6) > I would like to confirm for 2.6.29.3-155. > For me it mostly exhibits itself as font or image corruption after resume from > suspend. Michal, this is a different bug than what you see. Hezekiah sees his X server restarting, what you have is bug #495323. Hezekiah, do you still see crashes/restarts with recent rawhide? thanks, Kristian Actually my server also restarts occasionally (at least used to - im yet trialing the latest kernel updates to -167). Usually after the font corruption has progressed. Other times it just locks up (the kernel is running i can tell, but no input except for sys-rq works). I used to have this problem on PAE-140 kernel while starting X - it would just freeze up an I had to sys-rq it. When using the i586 kernel or only 2GB ram it did not happen (bug #501408). Thats why I once rebooted into the i586 kernel, hoping it would not have the problem but I saw font corruption right away. It looked as if the graphics didnt reinitialize on boot and retained the memory corruption. You are right, bug #495323 is a better description of my problem, but I have a feeling its all the same bug. The reporter of this bug - Hezekiah M. Carty has almost identical hardware to mine (core2 duo with 965GM), so I think he would be experiencing the same problems had he had 4GB ram and used the PAE kernel. I doubt the intel driver (which is obviously to blame) is much better on x64. The difference in configuration probably just hides the bug for later. After all, memory corruptions have the tendency to make the computer behave chaotically. This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping From what I can tell, this does not occur on Fedora 11. However, I am not certain if it is 100% fixed as I have not been using my F11 install much recently due to other Intel GPU hangs (reported here and upstream to the Intel/freedesktop.org folks). OK, so let's close it now, and if you find that this bug has actually not been fixed, you are very welcome to reopen it with additional information. Thanks for reporting this bug in the first place. I've just seen this on kernel-2.6.30.5-32.fc11.x86_64, xorg-x11-drv-intel-2.7.0-7.fc11.x86_64. Suspended with both LVDS and an external monitor attached, resumed with just the notebook's flat panel. I'll attach my Xorg log and dmesg below, but I can't find anything incriminating... Created attachment 358934 [details] [Comment #14] Xorg.0.log from failed session Created attachment 358935 [details] [Comment #14] dmesg |