Hi The video output on my Thinkpad X301 hangs on suspend / resume when KMS is enabled. I'm not too interested in researching the non-KMS use case, but in general things seem to work better when I go to console first. Jesse Barnes did some good debugging on this issue a couple of weeks ago: he has the same chip on a X200s, but doesn't see this issue while running the same (Ubuntu karmic) on the laptops. Back then I tried 2.6.30 rc5 through rc7, with no luck. Today, I tried 2.6.30 final with a manually built intel driver from git master. I still get the issue. The display is redisplayed upon resume, but no update occurs, caps lock doesn't respond. Last week, I would SSH into into the box to debug, but killing Xorg would hang the box completely. Today, I simply Alt-SysRq-K and gdm respawns a Xorg server just fine. Bye
Created attachment 26780 [details] sudo lspci -vvnn output
Created attachment 26781 [details] dmesg (after a couple of suspend/resume/alt-sysrq-k)
Created attachment 26782 [details] Xorg log
I tried using metacity in non-composited mode instead of compiz, but it didn't help. NB: sometimes I get a black screen on resume, and sometimes my desktop; I think it's just gnome-screensaver failing to kick in fast enough, but it could be part of the symptoms of the bug. In both cases the video output is hung, I don't see a mouse pointer and the caps lock key doesn't work; only alt-sysrq does, not ctrl-alt-fN.
If you can ssh in, can you also capture a GPU dump using intel-gpu-tools? The contents of dri/0/ in debugfs would help too (usually mounted at /sys/kernel/debug with "mount -t debugfs nodev /sys/kernel/debug").
Trying to cat /sys/kernel/debug/dri/0/* caused cat to hang; I limited to the i* files: for i in /sys/kernel/debug/dri/0/i*; do echo "== $i =="; sudo cat $i; echo; echo; done > ~lool/dri-0.txt will attach dumps
Created attachment 26812 [details] Gzipped GPU dump
Created attachment 26813 [details] GZipped dump of dri/0/i* files in debugfs
bug #22039 looks very similar.
NB: The fix from bug #20520 doesn't help.
Hopefully this is a dupe of http://bugs.freedesktop.org/show_bug.cgi?id=20520? Do you still see the issue? Could also be a dupe of #22383.
as I said in comment #10, it's sadly not a dupe of bug #20520; I'll check the patch in bug #22383, but it doesn't seem to be a too similar bug.
Oh sorry, missed that... yeah probably a separate issue from the DPMS one too.
Created attachment 27320 [details] [review] restore the modeset for every activated crtc
Hi, Loic Will you please try the attached patch on the latest linus git tree and see whether the issue still exists? Thanks.
I love you all! I'm leaving for GUADEC tomorrow with a working suspend/resume now! :-) So I built tip of git://git.freedesktop.org/git/xorg/driver/xf86-video-intel (4100abdf5d208bbcbb4ceabad0572c04221443c9) and tip of linux:torvalds/linux-2.6.git (d960eea974f5e500c0dcb95a934239cc1f481cfd) + the patch attached to this bug report (Restore the modeset for every activated CRTC) and: - that booted - it seemed to use KMS - Xorg works and I could suspend resume 3 times in a row Thanks! It feels slighly slower for some reason; in the past, I think I would get the Xorg image as soon as I'd pop the screen open (albeit frozen). The console ttys seem to be using highres and dmesg says: [ 3.450968] [drm] LVDS-8: set mode 1440x900 c during boot, so I'm pretty sure I'm using KMS, but my custom kernel behaves a bit differently from the distro kernel. Anyway, this is all fine and fixes the bug; I'm closing it, let me know if I should have kept it open
(Oh and xorg intel git tip included the fix of bug #22383)
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.