Resuming from suspend2ram my laptop using an intel 945G chip tries to restart X.Org several times before it goes back to console. I will attach the log of one of these attempts. I cannot start the X-Server by hand afterwards. The problem occurs only if drm is compiled in kernel (not as a module). Kernel 2.6.22.1 X.Org 7.2.0 intel-driver 2.1.0
Created attachment 10876 [details] log of the crash
a dup of bug# 11029?
No, bug#11720 is in fact no hurt just with some error messages.
Ooops, I should say bug#11029 is in fact no hurt just with some error messages.
Johannes, can you try the attached patch? If it doesn't apply easily, you could also try the latest DRM tree (git://git.freedesktop.org/git/mesa/drm). It fixes some of the suspend/resume problems people have been seeing. There are also some fixes in the latest X driver (git://git.freedesktop.org/git/xorg/driver/xf86-video-intel) that might help in your case.
Created attachment 12265 [details] Suspend/resume support for i915 DRM driver
*** Bug 13202 has been marked as a duplicate of this bug. ***
Ok, given that 9xx suspend/resume (and even 8xx suspend/resume) is working for lots of people now, I think we can assume this one is fixed. Please reopen or file a new bug if you find any problems. Thanks, Jesse
Sorry, i don't think that this bug is resolved. See my report in bug 10798, it seems to be the same error. I just tried libdrm from git, but nothing changed.
Created attachment 12669 [details] last resume-crash with libdrm from git
X doesn't crash when setting option "NoAccel" to true. But... no dri, no compiz and very slow window redraw (e.g. when moving windows). Just a temporary solution for me.
Can you get a backtrace of the crash? There are some instructions that might help at http://wiki.x.org/wiki/Development/Documentation/ServerDebugging?highlight=%28debugging%29
Created attachment 12692 [details] gdb backtrace of the crash I was not able to use gdb with the existing server after resume, but I found another way to reproduce the bug: - Start X - Kill X - Suspend - Resume - Start X with GDB (options -dumpShed and -kb) Please tell me if you need additional info.
Created attachment 12702 [details] gdb backtrace with debugging symbols Just learned how to create backtraces with gdb-symbols under gentoo. Not to myself: "debug"-useflag does NOT mean to include debugging symbols!
Sorry, I forgot to mention: the original crash with X running in background while suspending occurs when resuming and switching from vt1 to vt7. In my backtrace-szenario, I started the server on vt7 and switched back to vt1 -> crash.
Roland, does this problem still occur with the 2.2 driver release? And just to clarify a few things, does regular VT switching work before you suspend? The server only crashes after you resume your machine, regardless of whether it was running before or not?
The server doesn't crash on normal vt-switch, but only since i applied the patch from the following report: http://bugs.gentoo.org/show_bug.cgi?id=191822. The resume-crash did not changed. The patch can be reproduced in the following way: * Start system without X * optional: suspend and resume as often you want to. * start and exit X, as often as you want to, no problems. Feel free to switch vt. * suspend and resume the system * start x -> crash This is slightly different to the way used in my backtrace, but the error message in Xorg.0.log is the same, so I think this is the same problem.
Oh, and yes, I just used the current git version for testing. So I think the bug is not fixed in 2.2.
Upping severity
I think there are actually two bugs here, the one reported by Johannes (which should be fixed now) and the one Roland is talking about, which I think is a DUP of 10798, so I'm going to mark this one as such. *** This bug has been marked as a duplicate of bug 10798 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.