Shadow ROM memory PROBLEM

[Eric W. Biederman]

Adam Agnew <agnew at cs.umd.edu> writes:

> Hello. In our PCBIOS efforts, we're running into a snag.
> We're experience corruption of our shadow memory region, even after we've
> set it to read only (using the sis630).
> 
> mov eax, #0x80000070
> mov dx, #0x0cf8
> out dx, eax
> mov eax, #0x0000FFFF
> mov dx, #0x0cfc
> out dx, eax
> 
> we're not doing any pci writes at this point (once we've set it to read
> only), so does anyone else have any theories on what could cause this?

Things to check.
1) Is it really read only from software.
2) Is the shadow area really setup as ram.
3) How the fixed and variable mtrrs are setup over your code.

> Here's an example of the insanity going on:
> 
> Here, the bios has finished and we're ready to run lilo. The shadow memory
> is correct:
> 
> 000F3189L 260F015408       LGDT        fword ptr ES:[SI]+08
> 000F318EL 2E0F011E69F8     LIDT        fword ptr CS:[f869]
> 000F3194L B002             MOV         AL,02
> 000F3196L E680             OUT         80,AL
> 
> Then, we run lilo and we load an unmodified linux kernel. After a random
> amount of calls to int13 and int15 to copy the kernel into memory
> (sometimes it just takes 20 or so, sometimes 58, and sometimes it doesn't
> happen at all) the shadow memory gets corrupted. and we get stuff like
> this:
> 
> 000F3199L 260F01B002E6     LMSW        word ptr ES:[BX+SI]+e602
> 000F319FL 80011E           ADD         byte ptr [BX+DI],1e
> 000F31A2L 69F883C8         IMUL        DI,AX,c883
> 
> As you see, its all scrambled. The op codes get into a weird order.
> I'll try to illustrate with this mapping..
> 
> 260F015408 2E0F011E69F8 B002 E680
> 1111111111 222222222222 3333 4444
> 
> 260F01B002E6 80011E 69F883C8
> 111111333344 442222 2222
> 
> and the addresses in general are all shifted down.
> 
> Any ideas, suggestions, insights?

Unless the memory is not actually read only this does not sound at all
like memory correction (except possibly a random mem move).  I would
verify the read-only ness of your data, and I would check to see if you
might be changing a segment register you should not be.  I would be
especially suspicious of your interrupt routines, assuming you are talking
with interrupts to the IDE drive.

Eric