On 01/01/2014 06:46 PM, Paul Menzel wrote:
Dear coreboot folks,
the issue is still not solved, so here is an update.
First of all, my thanks go to Kyösti for helping me debug this issue in
#coreboot on <irc.freenode.net>.
According to Kyösti there is fairly strong evidence of RAM / stack
corruption during S3 resume.
Memtest 5.00b5 successfully passed twice run from GRUB 2 on hard disk
with coreboot and SeaBIOS payload. I’ll still have to test resume from
S3 with other memory modules.
Kyösti pushed a AMD K8/Fam 10h CAR rewrite to Gerrit . Additionally
he provided the attached diff  to capture a stacktrace. Please find
my logs with `PRINT_IN_CAR` set to 0 and 1 attached.
What the traces suggested is RAM access being unstable on S3 resume.
With stack moved to RAM, we saw issues like returning to incorrect EIP
from function calls and local variables getting wiped. A single build
could fail at numerous different ways.
Leaving RAM un-cacheable (not setting variable MTRR of [0x0 - RAMTOP[ to
write-back) when resuming from S3 seems to solve the problem of halting
in middle of romstage. On S3 resume it now loads ramstage and fails at
the time of MTRR (re-)programming. This is where it would set RAM to
Testing from other owners of the Asus M2V-MX SE would
be very helpful as
resume from suspend to RAM was supposedly working in the past for them.
And with different memory configuration and different CPU, those may
work like they did before. And the particular configuration of memory
you have may never have been tested for S3 resume until now.
We can compare memory controller parameters on power-on and S3 resume
and hopefully we locate the significant difference in register
programming there. JEDEC sequencing bringing DIMMs out of self-refresh
needs to be investigated too.