When resuming from hibernate the percentage indicator for re-reading the pages from hdd goes to 100% and then, just before actually resuming, the shift lock led starts blinking and the system is freezed. No backtrace is printed. Reproducible: Always This bug poses a regression from 'gentoo-sources-2.6.38'. A git bisect on 2.6.38.2 from git.kernel.org revealed commit ff518ea26654e05d325d996f6e3a7f5f569cc2d5 as the bad commit which is titled 'x86: Cleanup highmap after brk is concluded'. This commit basically brings commit e5f15b45ddf3afa2bbbb10c7ea34fb32b6de0a0e upstream and is part of the 2.6.38.2 kernel release. Note that my system, a Lenovo T400 notebook, is a 64-bit system with 4G memory. Besides, 'gentoo-sources-2.6.37-r4' shows the same bug for me while 'gentoo-sources-2.6.37-r1' is still working. However, the same commit (it is commit 72f2999e41d09468b29de855ffc02f94e87a675e for the 2.6.37.y line) is part of the 2.6.37.6 kernel release, which is shipped by 'gentoo-sources-2.6.37-r4'. However, I want to emphasize that I did not perform a git bisect on the 2.6.37 line as well. Workaround: after applying the patch attached, which reverses the bad commit, on gentoo-sources-2.6.38-r1 hibernating works again for me.
Created attachment 267711 [details, diff] reverts commit ff518ea26654e05d325d996f6e3a7f5f569cc2d5 Fixes the resume-from-hibernate bug for me.
I see this bug with gentoo-sources-2.6.38-r1 on an Acer Travelmate 5730, and your patch fixes it for me. Assigning to maintainers.
Created attachment 269849 [details] Kernel panic snapshot Hi there, ...ouch, I spent half a day debugging on 2.6.37-gentoo-r4, x86_64 AMD Turion 8-( For further details, this looks like the official kernel bug report: <https://bugzilla.kernel.org/show_bug.cgi?id=32652> I attached a screen shot of my laptop panicking just after loading the image. The call trace looks the same. Cheers, ^s p.s. Could anybody please rise a bit the importance?
Just saw that 2.6.38.3 has been tagged in git.kernel.org and commit 8f114f1414335ed352e54d0343909d7b69a81432 [1] fixes the problem in the same way as my patch does: it simply reverts the bad commit. In other words, the upcoming gentoo-sources should be free of this bug provided that it is based on >=2.6.38.3. [1] http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.38.y.git;a=commit;h=8f114f1414335ed352e54d0343909d7b69a81432
gentoo-sources-2.6.38-r3 released which contains linux patch 2.6.38.3
I had this problem on my Fujitsu Lifebook S760 too. Your patch fixed my problem too. Thanks.
(In reply to comment #5) > gentoo-sources-2.6.38-r3 released which contains linux patch 2.6.38.3 I guess we meant 2.6.38-r2. I just tested the new kernel and the bug disappeared for me.
