RAM Mapping Script

[Michael ODonnell]

>> (The nominally cost-effective thing to do is throw the computer out
>> and buy another one, but I trust you are aware of that and have
>> particular factors which are affecting the math.)
>
> I let principle override practicality all too often.  It irks me
> to toss a beautiful piece of engineering because one square micron
> of silicon leaks a little too much current for the refresh rate.

Yeah, you really should learn to squander resources more effectively.

>>  The error occurs at address 64h.
>
> INT 19h stores the code when the numeric keypad is used with the
> alt key.  Since the numeric keypad is not even enabled on the
> laptop, it it hard to guess why that interrupt would be accessed
> and how it would affect the functioning of these programs.  But...

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.

>> I'm not sure you can reserve that region to prevent the system from
>> using it (or if the system will work properly if you do).  On the
>> other hand, once the kernel switches into protected mode, I think
>> things get more complicated, so maybe it doesn't matter so much.
>
> Real or unreal mode, the location of the interrupt jump table is
> built into the processor, as has been pointed out.

Actually, since the days of the '286 (maybe even earlier?) the IA32
architecture has used the IDT register to point at the vector table
(official name: Interrupt Descriptor Table) wherever it happens to be.
The IDT defaults to being down at 0 after Reset but can be anywhere in
memory and this is true for all modes including Real mode.

There's a lot of moving parts here and I still don't have a good mental
picture of your situation but, IIRC, the IDT register is changed early
on during Linux startup so it's at least theoretically possible that if
your BIOS can tolerate that b0rken RAM long enough to get Linux loaded
into memory you could perform some trickery that caused the kernel to
ignore that zeroth page of physical RAM.

I can't believe this is a problem that nobody's dealt with before -
there's probably an obscure command line switch for just such occasions...