Comment 16 for bug 760842

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?