RAM Mapping Script

Coleman Kane cokane at cokane.org
Mon Mar 3 10:27:12 EST 2008


Ben Scott wrote:
> On Mon, Mar 3, 2008 at 9:25 AM, Coleman Kane <cokane at cokane.org> wrote:
>   
>> That spot of memory is off-limits because the kernel needs to preserve it
>> in the event that another process wants to enter a vm86 mode.
>>     
>
>   If a process switches to virtual x86 mode, wouldn't virtual memory
> page for address 0 (which includes the software interrupt table) get
> mapped to a per-process page in physical memory?  Would that have
> anything to do with the RAM at physical address 0x64?
>   
What usually happens under Linux / BSD, if I can remember properly is
that much of the memory content of that 1MB is duplicated to another
memory page, which is then mapped to the process's memory space. Ranges
that are supposed to represent Hardware I/O (framebuffer at 0xA000:0000,
console at 0xB8000:0000, NIC at 0xD800:0000 *maybe*, etc...) are
actually virtualized for the vm86 session. So if you got read error(s)
on that cell of RAM, you'll likely hit it when the process setup occurs.
This memory is "shadowed" so that multiple vm86 machines can't interfere
with one another. Much of the stuff mapped by devices into your memory
at 0xA000:0000 and above would be software code (such as the VBE stuff),
and would be accessed in a read-only / execute-only sort of manner. In
the old days, Memory-Mapped I/O was much less common and it was much
more SOP to have the device's BIOS map some software code into this
"high memory area" that could be executed by your 8086-compatible CPU
and have it perform the proper port I/O operations to get the desired
result.

I suppose it is likely that all of this could initially be mapped
read-write with CoW, making it allocate new pages on-demand, but actual
writing to the memory located at 0x0000:0064 (or 0x0006:0004 if you want
to get fancy) is definitely a no-no from your user program. This memory
must remain free from writes from userland, as the devices will still
respond to write operations in this area.

Usually, your OS or host application is providing a monitor on top of
the Vm86 session, so that when your program writes to 0xb8000:0000,
you'll get a nice printing of characters inside of your xterm, rather
than having them not show up at all (if your graphics card is in raster
mode), or worse (under standard-console-mode, writes here would make
characters get printed all over your screen).
>>  What problem is the memory defect actually causing that is troublesome ...
>>     
>
>   The OP stated, "Every few weeks some Linux program would go wacky.
> Each time is was a different program and a different wackiness.
> (There were not enough wacky observations to conclude that the same
> effect in the same program never ever repeated.)  Reboot restored
> proper operation."
>
>   He hasn't mentioned anything that really proves the wackiness is due
> to the bad RAM, although I think that's a reasonable assumption to
> make at this point.  My fear would actually be that the bad cell at
> physical address 0x64 is just the tip of the iceburg, and that other
> cells are developing issues over the week-long periods he mentions.
>
> -- Ben
>   
That's what it sounds like to me. Is there no way to turn off the RAM on
the motherboard on that system via the BIOS menu or even a jumper on the
motherboard?


--
Coleman



More information about the gnhlug-discuss mailing list