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.
I'm copying the stack from 0c8000-0cfffff to 1f8000-1fffff Here's the output when copying in 8 pieces
Copying testx from 000ced80 (001fed80)
0 dest 001f8000 src 000c8000 size 1000 1 dest 001f9000 src 000c9000 size 1000 2 dest 001fa000 src 000ca000 size 1000 3 dest 001fb000 src 000cb000 size 1000 4 dest 001fc000 src 000cc000 size 1000 5 dest 001fd000 src 000cd000 size 1000 6 dest 001fe000 src 000ce000 size 1000 ÿ dest 001ff000 src 000cf000 size 1000 Copying done Done
testx = 5a5a5a5a
Disabling cache as ram now
Notice the ÿ character when the top of the stack (location of testx) gets copied.
16 pieces (excerpt):
d dest 001fe800 src 000ce800 size 800 ÿ dest 001ff000 src 000cf000 size 800 f dest 001ff800 src 000cf800 size 800
Same character at the top of the stack
32 pieces:
1a dest 001fe800 src 000ce800 size 400 1b dest 001fec00 src 000cec00 size 400 ÿÿ dest 001ff000 src 000cf000 size 400 1d dest 001ff400 src 000cf400 size 400 1e dest 001ff800 src 000cf800 size 400
64 pieces:
36 dest 001fec00 src 000cec00 size 200 ÿÿ dest 001fee00 src 000cee00 size 200 38 dest 001ff000 src 000cf000 size 200
Thanks in advance, Myles
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).
Throwing out the complete v2 K8 CAR disabling code and replacing it with the v3 code is one of the possible fixes. I will do that probably this May. By the way, the global variable infrastructure in v3 is one of the reasons why stack switching in v3 is much less painful.
Regards, Carl-Daniel
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).
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.
Thanks, Myles
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).
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.
Regards, Carl-Daniel
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).
I fixed that with recent patch. Is it what you checked?
Myles, please check
1) If it does work without my patch ;) 2) Add the
static void set_init_ram_access_uc(void) { set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_UNCACHED); }
And call the set_init_ram_access_uc instead of set_init_ram_access and call again set_init_ram_access after the copy.
The CAR code as it is now is doing at least evictions to L2 maybe this will help.
Rudolf
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).
I fixed that with recent patch. Is it what you checked?
I thought I had updated since then, but it turns out that I hadn't. One of these days I'll look into why the build strings never update.
Myles, please check
- If it does work without my patch ;)
No strange characters :) It makes it fail more reliably later, which is good. I'll go back to debugging that.
- Add the
static void set_init_ram_access_uc(void) { set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_UNCACHED); }
And call the set_init_ram_access_uc instead of set_init_ram_access and call again set_init_ram_access after the copy.
I'll look at that too.
Thanks, Myles
- Add the
static void set_init_ram_access_uc(void) { set_var_mtrr(0, 0x00000000, CONFIG_RAMTOP, MTRR_TYPE_UNCACHED); }
And call the set_init_ram_access_uc instead of set_init_ram_access and call again set_init_ram_access after the copy.
I'll look at that too
That didn't make any difference for my symptoms, but I'm interested in why you'd want to set it uncacheable.
Thanks, Myles
-----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
is this possible coreboot works on dell gx270
-
Carl-Daniel Hailfinger -
Miguel Ross -
Myles Watson -
Rudolf Marek