Most recent kernel where this bug did *NOT* occur: none Distribution: Ubuntu, Gentoo Hardware Environment: Laptop Lenovo Thinkpad X60T Software Environment: Problem Description: When the Laptop runs for many (6+) hours, a resume from suspend to ram is very likely to result in a reboot or freeze. If the Laptop runs for a shorter time, both suspend built into the kernel and s2ram will very likely resume successfully. I was looking for help on the linux thinkpad mailinglist, suspend-devel mailinglist as well as the linux-pm mailinglist with no success. The Debugging didn't seem to help, i got "hash matches device ..." messages at boot but they all pointed to a terminal device and not dependent on whether the last resume froze/rebooted or was successfull. I dont know what else to do, i have this issue since many months. I found another X60T Linux user with the same issue. Steps to reproduce: Buy a Lenovo Thinkpad X60T for 2000 Dollars, run any Linux Distribution for 6+ hours, suspend-to-ram and resume.
Please run this tool for 6 hrs on you X60T. http://www.linuxfirmwarekit.org/ Then try suspend and resume and report results. It's too expensive to spend 2k for just debugging. hehe :-)
I think shaohua has a X60, right? Can you reproduce this? It looks like a dup of bug# 6166. The bad news is that if it's really a dup, it's not HW specific but related with cpufreq... it makes sense to keep this bug open and re-test if it's really gone in 2.6.21+...
Not reproduceable here with a X60. Can you attach the output of 'lspci -vvvxxxx' for cases of just after boot and just before the resume fail. you can write a script to do the command and then suspend, and send me the last one with resume failure.
The problem has vanished. I dont know what fixed it, but iirc it just worked when i switched to gutsy. I used suspend/resume dozens of time since then and they all worked fine (except for some video-driver issues but i heard its being worked on).
The bug vanished strangly.