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 [1]. Additionally he provided the attached diff [2] 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 write-back cacheable.
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.
Kyösti