|Summary:||[945GM] X freezes some hours after suspend-to-RAM|
|Product:||xorg||Reporter:||Martin Pitt <martin.pitt>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|Priority:||medium||CC:||apw, bryce, jbarnes|
|i915 platform:||i915 features:|
Description Martin Pitt 2009-09-14 04:21:32 UTC
Created attachment 29513 [details] X.org log Hello, After a clean boot, I have never ever had a single freeze any more for months now, so in general things work very well and smoothly on my i945. However, after a suspend/resume from RAM cycle, X.org freezes after some time, anything between ten minutes and several hours. Usually it's something like 2 hours. This isn't triggered by anything "obvious" like switching desktops in compiz or starting a program, it usually just happens while typing text in a terminal (what I do most of the time, after all). I tried to reproduce it using a "compiz stress test" script which runs 2 glxgears, a video, several terminals, and constantly switches workspaces, but that doesn't trigger it. So unfortunately reproducing this always takes very long. I attach the usual set of debug logs, like GPU/register dump, etc. In dmesg you see that the kernel complains about the hung i915 process. When SSHing into the machine, I can still run programs normally, but the Xorg server is unkillable (kill -9 just turns it into "kernel deep sleep" (D) state), and it's impossible to get rid of the screen freeze. Bryce Harrington, the Ubuntu X.org maintainer, has heard of several other platforms where this happens, and asked me to file the bug upstream. Setting severity major as per discussion with Jesse Barnes on the last Ubuntu Developer summit. This sounds a bit similar to bug 23689, but I have different hardware, and the reporter there said it's fixed for him now. Thanks, Martin Hardware: Laptop: Dell Latitude D430 Card: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) Screens: Internal LVDS 1280x800 (turned off), external 1280x1024 TFT through DVI, using KMS Versions: Kernel: 2.6.31 final intel: 2.8.1 mesa: 7.6.0 prerelease, git snapshot from 2009-08-17 (commit 7c422387) libdrm: 2.4.13
Comment 5 ykzhao 2009-09-15 23:33:09 UTC
Will you please try the following patch and see whether the issue still exists? The patch: drm/i915: Check that the relocation points to within the target http://lists.freedesktop.org/archives/intel-gfx/2009-September/004243.html Thanks.
Comment 6 Martin Pitt 2009-09-15 23:57:35 UTC
Yep, will do. I installed a test kernel now with the patch you mentioned plus this one: http://people.canonical.com/~apw/lp429241-karmic/0001-UBUNTU-SAUCE-drm-i915-Pad-ringbuffer-with-NOOPs-befo.patch (Currently being tested and forwarded upstream) We also got a new mesa package with this patch http://cgit.freedesktop.org/mesa/mesa/commit/?id=acfea5c705f383692e661d37c5cd7da2f3db559b yesterday which is supposed to fix some screen corruption and was said also to trigger this. I'll give my system a good beating with those and report back. Thanks!
Comment 7 Martin Pitt 2009-09-16 10:17:48 UTC
Unfortunately I can still reproduce the freeze even with these patches.
Comment 8 ykzhao 2009-09-17 20:37:45 UTC
(In reply to comment #7) > Unfortunately I can still reproduce the freeze even with these patches. Will you please attach the gpu dump/register dump before and after suspend/resume? thanks. >
Comment 9 Martin Pitt 2009-09-18 05:39:47 UTC
Created attachment 29666 [details] register/gpu dump before/after suspend Sure, here it comes. Sorry for the compression, gpu dumps are too big to attach uncompressed.
Comment 10 Martin Pitt 2009-09-18 08:27:29 UTC
Out of interest, why was this made private?
Comment 11 Julien Cristau 2009-09-18 11:51:08 UTC
(In reply to comment #10) > Out of interest, why was this made private? > you restricted it to the 'x.org security' group with comment#6 as far as I can tell.
Comment 12 Martin Pitt 2009-10-08 02:30:22 UTC
Just for the record, still happens with mesa 7.6.0, intel 2.9.0, and linux 126.96.36.199. (I didn't actually expect the new mesa/intel driver to fix this, since this looks like a problem in i915.ko).
Comment 13 ykzhao 2010-03-14 22:17:33 UTC
(In reply to comment #12) > Just for the record, still happens with mesa 7.6.0, intel 2.9.0, and linux > 188.8.131.52. (I didn't actually expect the new mesa/intel driver to fix this, > since this looks like a problem in i915.ko). Hi, Sorry for the late response. Will you please try the 2.6.33 stable kernel and see whether the issue still exists? (Please add the boot option of "drm.debug=0x04") If the problem still exists, please see whether the system can be accessed by using ssh and attach the output of dmesg, Xorg.0.log. Thanks. yakui >
Comment 14 Martin Pitt 2010-03-16 02:20:57 UTC
Yay! I have run .33 for two days now, with several suspends, and the corruption is gone. Thanks!
Comment 15 Martin Pitt 2010-03-16 02:26:48 UTC
Argh, tough luck. It was working for two days, and ten minutes after I close the bug I get the screen corruption again.. I'll provide debug output.
Comment 16 Martin Pitt 2010-05-03 03:56:10 UTC
I have run my laptop with 2.6.34rc5 for several days, and I never got a complete freeze. I do get local screen corruptions quite often after resuming (primarily in gnome-terminal, where retangles of text go missing or are only painted in green instead of black, etc), but those are much easier to deal with than system hangs. Thus I close this for now.