Created attachment 24922 [details] pm-suspend.log I have used suspend/hibernate in the past, but not for a while. This is an HP DV2910US laptop with Intel 965 chipset. I can suspend/hibernate apparently all day long when booted to a recovery console (X not active). As soon as X is then activated (startx), suspend/hibernate becomes broken. It seems to do all the work required to suspend (including switching VT with s2ram). But at the instant when the machine would feel like it would normally suspend or power off, instead it totally hangs with no further activity. If I boot into X and do not try to suspend from the console beforehand, I can suspend/hibernate precisely once per session. The second attempt will produce the above behavior. The machine has the latest BIOS from HP and I am running Ubuntu Karmic with some packages pulled in from Lucid.
Created attachment 24923 [details] lspci -vvvn
Created attachment 24924 [details] dmidecode
Created attachment 24925 [details] Xorg.log
1. Please attach the output of "lspci -vv". 2. What kind of graphics adapter is there in the box? 3. Have you upgraded X recently? 4. What was the last working kernel?
1. attached 2. Intel 965 (also tried with nomodeset) 3. Yes, from karmic to lucid packages, but it didn't solve the problem 4. If I had to make a guess I'd say it was 2.6.30 or prior.
Created attachment 24929 [details] lspci -vv
Methinks this should be reassigned to DRI. Rafael, I'll assume that you'll take care of this, if needed.
Agreed, so reassigning.
Can you try the drm-intel-next branch from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel? Also, please try using echo mem > /sys/power/state from a xterm or something to isolate any pm-suspend related funkiness.
I tried drm-intel-next, but got a blank display at boot and thereafter unless 'nomodeset' was passed. Using nomodeset, the same suspend/resume problem persisted with that kernel. I did the suspend via /sys/power/state directly.
Make sure you have CONFIG_FRAMEBUFFER_CONSOLE=y in your kernel config or you'll get a blank display. Also you'll need a recent version of xf86-video-intel (2.8 at least I think) to work with the new KMS bits.
I have it enabled and still get a blank display at bootup with that kernel.
xserver-xorg-video-intel is 2.9.1 (Ubuntu)
Hi, I think i can confirm this bug. I have a Intel 945GME. I'm running 2.6.33-29-pae on a opensuse 11.1 box with the intel drivers 2.10.0 and Xorg 1.7.5 I can also say that the problem wasn't there on 2.6.32-39 but I'm not sure when exactly it appeared. Also, the first time i noticed suspend to disk just froze when running X. Then there was some versions in which it would just work once. On the my current kernel it is back to the initial behaviour (freezing on first try). I will attach lspci -vv now. If there's any other way i can contribute just tell!
Created attachment 25391 [details] lspci -vv
No longer a bug in 2.6.34. However, I am still unable to get display at boot with KMS active.
Do you still see the blank display problem? Even with a stock ubuntu kernel from the xorg edgers repo?
Still blank with 2.6.34.1 from kernel.org (using ubuntu kernel config).
Does VT switch also cause a blank screen? If so, this could be an X problem I fixed recently. xorg edgers should have a fixed package.
X VT switch works fine. KMS still gives me a blank screen at boot necessitating 'nomodeset'.
Can you file a new bug at bugs.freedesktop.org for the blank screen problem? http://intellinuxgraphics.org/how_to_report_bug.html has info on which files we need. In particular, I'd like to see the boot log from a fresh boot (before X starts) with debug=4 (the drm module option). Thanks, Jesse
2.6.35 put an end to the KMS issue finally. Mode setting at boot is working correctly now.
Cool, thanks for the update.