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
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_DEBUG=true has been set
- contains after line 180 the list of kernel modules loaded.
Created attachment 244645 [details]
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  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 , was merged one day after 18.104.22.168 was released. Hopefully, 22.214.171.124 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.
Thank you very much for all the tests you did and for the git bisect
Assigning to kernel team
Little update: kernel 126.96.36.199 (and gentoo-sources-2.6.35-r5) does not contain a fix.
I wonder if this is the patch:
1. gentoo-sources-2.6.35-r8 (which is based on kernel 188.8.131.52) 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:
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.