After calling 'pm-suspend' the screen turns black as expected. But instead of going completely into suspend the moon-LED blinks, power-on and battery symbol stays on, the backlit of the display remains on and the system is freezed. - Alt+sysrq does not respond; one has to power off the notebook (Lenovo T400) - It is a regression: no problems for gentoo-sources-2.6.34* (or older). Problem still present in vanilla-sources-2.6.36_rc1 - Since many similar problems have been reported for 2.6.35, I tried the (pseudo-)solutions I found in the net. The following did not help: * kernel-param: acpi_sleep=nonvs * kernel-param: acpi_sleep=nonvs terminal=tty0 * removing TPM support from kernel config Reproducible: Sometimes Steps to Reproduce: The problem does not occur deterministically. Sometimes suspend works. However, it seems that suspend works from a non-X terminal. And it seems that the problem always occurs right after booting when kdm shows up.
Created attachment 244643 [details] pm-suspend.log - PM_DEBUG=true has been set - contains after line 180 the list of kernel modules loaded.
Created attachment 244645 [details] /var/log/messages Contains the corresponding section of /var/log/messages where suspend failed.
Created attachment 244647 [details] Kernel config of non-working gentoo-sources-2.6.35-r4
I did a 'git bisect' which revealed commit d1b851fc0d105caa6b6e3e7c92d2987dfb52cbe0 on my system. It seems that this commit already gained attention by the kernel developers. According to the message [1] the problem is fixed in 2.6.36-rc2. It seems that I can confirm this on my machine with vanilla-sources-2.6.36_rc2. The fixing commit, according to [1], was merged one day after 2.6.35.3 was released. Hopefully, 2.6.35.4 will contain a fix as well in order to make 2.6.35 usable again. Summarizing: bug fixed for 2.6.36_rc2, but still open for the 2.6.35 branch. [1] http://groups.google.com/group/linux.kernel/browse_thread/thread/f7367674bc7ca2c7/d5296027295dac26?show_docid=d5296027295dac26
Thank you very much for all the tests you did and for the git bisect Assigning to kernel team
Little update: kernel 2.6.35.4 (and gentoo-sources-2.6.35-r5) does not contain a fix.
I wonder if this is the patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=72bcb2690927f04c0479cd0d83825f09f3bf4d4f
Some news: 1. gentoo-sources-2.6.35-r8 (which is based on kernel 2.6.35.5) does not fix the problem. 2. the patch based on commit 72bcb2690927f04c0479cd0d83825f09f3bf4d4f applied on gentoo-sources-2.6.35-r8 does not fix the problem. 3. the patch based on commit 90eb77baaea35c591bd324b31e9eac032bd603c9 [drm/i915/suspend: s/IS_IRONLAKE/HAS_PCH_SPLIT/] applied on gentoo-sources-2.6.35-r8 does not fix the problem. However, the bad commit d1b851fc0d105caa6b6e3e7c92d2987dfb52cbe0 did not touch the file i915_suspend.c and therefore point 2. and 3. make sense. I suggest one tries more patches collected by the merge commit 4238a417a91643e1162a98770288f630e37f0484 which modify one of the following files: - i915_dma.c - i915_gem.c - i915_irq.c - intel_ringbuffer.c Or, one could start a git bisect from 2.6.36-rc1 to 2.6.36-rc2 to find the fixing commit.
Well, it seems that the 2.6.35 line stays with this bug forever. However, the brand new gentoo-sources-2.6.36 kernel works well, as expected due to comment #4.
gentoo-sources-2.6.35-r5 stable on amd64.
(In reply to comment #10) > gentoo-sources-2.6.35-r5 stable on amd64. To be precise, gentoo-sources-2.6.36-r5 got stable on amd64.
For the first time readers: this bug happened only to those with i915 drm driver. (Intel's gpu.)
