-----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006@gmx.net] Sent: Monday, March 08, 2010 7:56 PM To: Myles Watson Cc: 'coreboot' Subject: Re: [coreboot] Strange corruption with printk
On 09.03.2010 03:16, Myles Watson wrote:
On 09.03.2010 00:18, Myles Watson wrote:
I divided the CAR copy into pieces to debug memory corruption that I'm seeing. It seems to fit a pattern, but I'm not sure what would be
causing
it. Any ideas would be appreciated.
To be honest, if post_cache_as_ram() works at all on K8, it is mostly luck.
:)
The memory copy is not inline asm (will lead to subtle corruption), the memory copy and the stack switching are not in one inline asm block (gcc is free to insert arbitrary code in between), and the stack is switched in the middle of a function (gcc may use some non-clobbered regs to access the old stack, or simply die).
Interestingly enough, the corruption is before the stack switch. I guess you're saying that gcc is reordering instructions so that it corrupts part of the loop?
I'll try adding some post codes before and after the copy. gcc shouldn't reorder around serializing instructions, right?
Throwing out the complete v2 K8 CAR disabling code and replacing it
with
the v3 code is one of the possible fixes.
Unfortunately, v3 never worked for K8.
IIRC CAR disable worked for K8 in v3, but later K8 init failed. Maybe it makes more sense to modify my suggestion above to "replace some of the code with v3". The three-stage-CAR-disable-jump design in v3 is something I believe to be superior to the stack switching in v2. Anyway, I think that having the stack copy inside the same asm statement as the stack switch could probably help.
I'll look into it.
Thanks, Myles