Red Hat Bugzilla – Bug 494705
X + Intel driver becomes unstable after suspend/resume cycle if the state of an external display is changed
Last modified: 2018-04-11 12:02:29 EDT
Description of problem:
Using the latest rawhide packages as of this submission (and since installing the F11 beta), I see frequent X restarts when using some combination of xrandr - either through the command line or the Gnome configuration app - and suspend/resume.
I have Desktop Effects/compiz enabled.
The system is a Thinkpad R61 with an Intel Core2 Duo CPU, Intel 965GM video
Version-Release number of selected component (if applicable):
Fedora rawhide (F11) x86_64
Every time, though the time it takes for X to restart varies.
Steps to Reproduce:
1. Attach or remove an already attached external display
1a. Optionally enable and/or disable the external display
2. Suspend to ram
3. Resume from suspend
4. X generally restarts some time after the resume. It may happen immediately, or it may take several minutes.
X restarts unexpectedly
X doesn't restart until I tell it to
I have removed the VT switch on suspend script as described on the Intel video test day wiki page. I have not noticed a deciding factor for when X restarts immediately on resume and when it takes time to restart.
Simply suspending my laptop, attaching an external monitor, then resuming the laptop from suspend has caused this problem.
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 22.214.171.124-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 126.96.36.199-155.
> For me it mostly exhibits itself as font or image corruption after resume from
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?
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:
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-188.8.131.52-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