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?
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?
- Adam Agnew
Adam Agnew agnew@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
-
Adam Agnew -
ebiederman＠lnxi.com