RAM Mapping Script

[Coleman Kane]

Michael ODonnell wrote:
>   
>> You won't be able to do this from userland.  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.
>>     
>
> Maybe I haven't been following this thread closely enough, but I
> don't see how either User mode accesses or vm86 mode would matter.
>
> I figure that once the kernel has pointed the IDT register elsewhere
> that zero'th page of RAM loses any special status and goes into a pool
> where it's eligible for allocation like any other.
>
> Well, OK - maybe not like any other.  Using the "crash" utility
> I queried the system's mem_map[] and it appears (at least on this
> steam-powered RHEL3 machine, assuming I'm looking at the correct
> bit definitions in include/linux/mm.h) that the first dozen pages
> are reserved:
>
> 	.
> 	.
> 	.
> crash> kmem -p
>   PAGE     PHYSICAL   MAPPING    INDEX CNT FLAGS
> c100002c          0         0         0  0 8000
> c1000068       1000         0         0  0 8000
> c10000a4       2000         0         0  0 8000
> c10000e0       3000         0         0  0 8000
> c100011c       4000         0         0  0 8000
> c1000158       5000         0         0  0 8000
> c1000194       6000         0         0  0 8000
> c10001d0       7000         0         0  0 8000
> c100020c       8000         0         0  0 8000
> c1000248       9000         0         0  0 8000
> c1000284       a000         0         0  0 8000
> c10002c0       b000         0         0  0 8000
> c10002fc       c000         0         0  0 0
> c1000338       d000         0         0  0 0
> c1000374       e000         0         0  0 0
> c10003b0       f000         0         0  0 0
> c10003ec      10000         0         0  0 0
> c1000428      11000         0         0  0 0
> c1000464      12000         0         0  0 0
> c10004a0      13000         0         0  0 0
> c10004dc      14000         0         0  0 0
> 	.
> 	.
> 	.
>
> ...so just for fun I wrote NULLs to that first page (with
> before and after displays for verification) thus:
>
>    dd bs=1k count=1              if=/dev/mem | hexdump -C
>    dd bs=1k count=1 if=/dev/zero of=/dev/mem
>    dd bs=1k count=1              if=/dev/mem | hexdump -C
>
> ...and the system kept on running, which indicates only that the
> IDT is elsewhere, though I'm still not %100 certain the page isn't
> in use for some other purpose.
>   
You are right, the IDT is elsewhere. In fact, the real-mode IDT (also
called the IVT, which would be at that location) and the protected-mode
IDT that you are talking about are two completely different data
structures with different formats. This was my point, that this memory
would never be used by the Linux kernel or any applications during
normal operation. However, when vm86 mode is set up, this first 1MB of
RAM is typically copied from the first 1MB of system RAM to populate the
"virtual 1MB" in your vm86 process. So my point with the vm86 mode talk
was that if the memory at 64h were the *only* memory that was actually
bad, then this problem should affect your system except during cases
where the kernel is attempting to set up a VM86 process.

My guess is that more RAM is also bad, just less obviously bad. Have you
tried running memtest86 with some of the more exhaustive tests on this
system?

--
Coleman Kane