RAM Mapping Script

[Jim Kuzdrall]

On Sunday 02 March 2008 13:28, Ben Scott wrote:

    Boo-hoo!  Still the same memory error.  Apparently Dell didn't 
shuffle RAM modules on this one.

    I can't say I am making any progress toward saving the computer, but 
I am learning a lot.  Thanks guys.

>From Michael ODonnell

> Que?  It's been ages since I thought about this stuff but I'm pretty
> sure int19h is (or was, when dinosaurs roamed and I was versed in
> this stuff) the vector that points to some sort of booter code;
> nothing to do with keypads.

    Right.  I was looking at 0040:0019 in the variables page. 

> the IA32
> architecture has used the IDT register to point at the vector table
> (official name: Interrupt Descriptor Table) wherever it happens to be.

   I knew that!  I think.  Once upon a time - but I forgot.  Yes, the 
x86 instructions LIDT AND SIDT load and store the register which points 
to the table in the protected mode.  Makes sense.  All other memory 
accesses must go through a Descriptor Table, so why handle the 
processor services differently.

>From  VirginSnow at vfemail.net

> Somewhere, floating around the 'net, there's something called the "bad
> RAM" patch for the linux kernel.

   I saw that too.  It might have been needed to solve a memory 
exception problem with the DEC Alpha chip.

Summary:
   Memory error is in on-board chip; impractical to replace.
   Linux maps the interrupt table elsewhere for protected mode, likely
   The RAM at the memory error acts like it is in the stack area
   There is nothing resembling memmap or any related thing on this Linux 
system

   So, the next thing to try is a program that executes right after boot 
and puts 128 bytes of zeros on the stack and stays in the background 
doing nothing.

Jim Kuzdrall