My Thinkpad T41 freezes approx. 20-50% of all hibernation attempts.
Steps to reproduce:
(1) start hibernation, e.g. "sudo pm-hibernate"
The "moon" LED blinks now. If all goes right, blinking stops shortly after and writing RAM to disk begins; computer turns off after this. If not, blinking stays indefinitely -- freeze. Magic Sysrq keys don't work either.
I first noticed it in my distro's (Ubuntu) 2.6.35 stock kernel. After bisecting (using the mainline vanilla kernel) for quite a while, I could find out the first commit where this appears (see below). Problem persists even in 2.6.36. I tried using help of /sys/power/pm_trace, but most of the time there was no hash match at all. The bug I filed in Launchpad (LP #623550) shows at least four other people affected. In another bug (LP #661711) about probably the same cause other Thinkpads and brands seem affected too.
| commit 7b51755c3b38483b574d363d5ee587283c3f7999
| Author: KOSAKI Motohiro <firstname.lastname@example.org>
| Date: Mon Dec 14 17:59:12 2009 -0800
| vmscan: kill hibernation specific reclaim logic and unify it
I'd like to help fixing this bug, but after looking at the commit I decided I'm not competent enough on how to go from here. How can I help?
When exactly does the box hang? Is it before the image is created or after
Is the system 32-bit or 64-bit?
Please do the test:
# echo core > /sys/power/pm_test
# echo disk > /sys/power/state
(it should return to the command prompt in 5-10 sec.) and see if you are
able to reproduce the symptoms.
I'm quite sure it freezes before image creation; see below.
The system is 32-bit (Pentium M 1,6 GHz).
Using your test I could reproduce the freeze, *but*:
- Just looping the test with 10 s sleep in between went well > 50 times (I canceled after that).
- Allocating 500 MB of memory for a process, doing the test and freeing/reallocating after "wakeup" proved successful after two(!) tries. It froze again.
(I allocated memory using a Python interpreter, i.e.:
>>> a=600000000*"a" # allocate
>>> a=None # free)
It's great that kernel bugzilla is back.
can you please verify if the problem still exists in the latest upstream
bug closed as there is no response from the bug reporter.
please feel free to reopen it if the problem still exists in the latest upstream kernel.