In the meantime, I did further testing on what is causing this. I came across 2 different hints:
1. When suspending/resuming, the motherboard may leave certain parts of "lowmem" in a corrupt state. The default parameter for the kernel is 64K, which it constantly monitors every 60 seconds as well as after resuming. Some people report fixing their suspend/resume by increasing this number. It can be done by adding ... memory_corruption_check_size=128K ... to the kernel line in /boot/grub/menu.lst. I tried several different values but was never able to properly resume. In total, I tested kernel 2.6.32 (lts), 2.6.38-8 and 2.6.39-rc5 with this method, but it made no difference. 2. There is a wiki on debugging kernel suspend (https://wiki.ubuntu.com/DebuggingKernelSuspend) by letting the kernel trace its actions. The commands used are sudo sh -c "sync; echo 1 > /sys/power/pm_trace; pm-suspend" As I wrote before, my machine seems to automatically reset itself very early during a resume (which is probably done, because it can be potentially overclocked and wrong settings may otherwise render it broken). So, in this state after it restarts itself, I cannot do much but hard reset it, reboot and then check the dmesg output. In contrast to the wiki article, I could not find any line in dmesg that said hash matches drivers/base/power/resume.c:46 however I found the (probably meaningless) "Magic number" line. Does that mean that the kernel never gets to the resume step at all? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/760842 Title: Natty Narwhal/Sandy Bridge Suspend Fails -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
