Created attachment 19259 [details] Xorg log after a resume and killing X (to avoid hardlock) The title gives the general idea but, if I suspend my machine via echo mem > /sys/power/state or via the gnome scripts it will suspend fine. When it resumes however, it will hang when it tries to re-enter X. So long as I leave it in console, it will not hang. If I disable Accel and ensure that the drm module does not load, resume from suspend works just fine. Further, should I instruct the machine to restart X instead of trying to enter my existing session (with all my work), it will start a new session with glitches. It believes at this point that my VGA port is connected to a monitor (it is not), and that my screen resolution should be 1152x864. It also incorrectly reports the physical size of the screen. I am running Ubuntu 8.10 Alpha kernel: 2.6.27-rc7 Xorg: 7.4 XServer: 1.5 Intel Driver: 2.4.2 Frustration level: Maximum Hardware: Lenovo Thinkpad T500 w/ Intel G45 (no ati card) 3GB of DDR3
Created attachment 19260 [details] Normal Xorg log after a fresh boot
Could you try xf86-video-intel git master?
Git was installed, bad bad things happened. - Suspend was (as far as I can test) not fixed. - When I switch to VT, Xorg crashes causing GDM to fire up a new session - Above bug breaks suspend scripts that switch to a vt first - Doing echo mem > /sys/power/state suspends properly but presents a frozen (and quite colorful) Xorg on resume
Created attachment 19265 [details] ModeDebug Xorg.0.log Here is a xorg log with modedebug enabled
Do you mean current master breaks VT switch on your T500?
Yes, that is exactly what I mean
What libdrm version are you using? Eric has fixed an assert issue within libdrm_intel on drm git master, which caused VT switch aborted X.
libdrm Git from Sept 22, 2008
I updated to your bzr version of libdrm and your latest version of intel_drv.so. Things seem to be working now. I will reopen if the issue re-appears. Thank you!
Bad news. While the update has considerably improved the reliability of suspend. Occasionally I still get the same freezing as originally described. This still leaves suspend somewhat useless. It probably occurs 10-20% of the time now as opposed to 95% of the time.
Created attachment 19318 [details] Xorg log from a failed resume hang I hope this xorg log contains some useful information. Some of it looks looks useful. This is a log from an Xorg that was alive during a failed resume.
This needs to be retested against current drm-intel-next kernel and master xf86-video-intel. Resume issues is one effect we expected we could see from the bad stolen memory accounting.
I am getting this same problem on my T500 with current git master of both libdrm and xf86-video-intel and kernel 2.6.27.4 with this patch applied: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff;h=82e14a6215cbc9804ecc35281e973c6c8ce22fe7 Should I test with the drm-intel-next as well, and if so where do I pull it from (is it the one on kernel.org)?
For more information, here is a (looks to be the same) bug on the Ubuntu Launchpad: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/276943 For me, this is a regression. S3 worked fine on my T400 in Ubuntu 8.04, and not in 8.10.
More, hopefully helpful, information: The following workaround apparently works for some people: http://ubuntuforums.org/showpost.php?p=6105510&postcount=12 Also mentioned here: http://www.thinkwiki.org/wiki/Install_Ubuntu_8.10_(Intrepid_Ibex)_on_a_Thinkpad_T400
Russell, do you mean this is a problem with SMP suspend/resume? We're still pending on test result of this bug. Could you test with Eric's kernel tree? which has recent gem fix and includes Keith's fix for save/restore render standby in suspend/resume.
It is interesting that forcing uniprocessing is a workaround. As commenters in that thread imply, it would seem the bug has something to do with a lack of proper mutual exclusion somewhere in the driver. I know very little of the driver itself, or how X makes use of it, so I have no idea if this is the case. I imagine that would be better answered by a driver developer such as yourself. I was only attempting to provide more information about the bug, and link the problems across bugtrackers. As for running from Eric's kernel tree, I've never compiled the intel driver from source, so it will take me a little bit to get setup and running. I'll try to get that done soon and get back to you.
I have the same bug with my T400. I've tested it with the drm-intel-next kernel branch, and 2.6.28 rcs, and the intel driver from git, but it all fails to resume properly. I did however get it working sometimes, but it was very unreliable. I have to put in "NoAccel" "true" in my xorg.conf to get hibernating working.
Also, disabling the other core fixes this issue for me as well.
My T500 also fails with git master and drm-intel-next from last Monday.
Jian, can you test this on T500 machine?
reassign to who has the machine now.
I tested on my Lenovo T500(GM45-64bit) with 4G memory, it works well with DRI enabled. Following is the configuration: arch: x86_64 Libdrm: (master) 9c8d634e687a5a5b5d314b3fd5b34cc17a217139 Mesa: (mesa_7_4_branch) 7e8f2c56c00f93ad55842dc5e3b123a1fcf74b3c Xserver: (server-1.6-branch)1f729b42d567ae9533ac0e467afc9fbc83390776 Xf86_video_intel: (master) 3aa8591abfbe8db0f13912910c850fdd748808df Kernel: (drm-intel-next) 9ac37e9d74785997abdd344866b648dd213aae04
symptoms appear to be the same as bug #20214 -- see there as to why it probably fails for OP on 2.6.27-rc7 but works for 2.6.28 as in comment 23
bug reporters, please reopen if the patch commited for bug# 20214 doesn't work for you. *** This bug has been marked as a duplicate of bug 20214 ***
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.