RAM Mapping Script

Ben Scott dragonhawk at gmail.com
Sun Mar 2 13:28:50 EST 2008


On Sun, Mar 2, 2008 at 7:53 AM, Jim Kuzdrall <gnhlug at intrel.com> wrote:
>     I have a Dell 2650 with one byte of bad RAM.

  I take it you mean a Dell Inspriron 2650, and not a Dell PowerEdge 2650.

> Unfortunately, it is in low RAM which resides on the board.  It is not practical to replace
>  the memory chip.

  If you've got a DIMM installed in addition to the RAM soldered to
the main board, try removing the module and running the tests again.
I've heard of hardware designs doing strange things, like presenting
add-on memory first when installed.  Perhaps that is myth (on x86, at
least), but worth a shot if you're trying to revive old hardware.
(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.)

>  The error occurs at address 64h.

  As others have pointed out, that's inside the software interrupt
vector table of the 8086 real-mode architecture.  You may be doomed.
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.

>  The kernel has a function, mmap(), which allows one to reserve
>  4,8,16,... bytes of memory at a specific physical address for a
>  process

  If you're talking about the mmap(2) system call... I don't really
know much about how it works, internally, but the man page leads me to
believe you're not guaranteed the kernel will actually map the virtual
address mmap() returns to a specified physical RAM address.  I'm also
not sure it would be enforced as exclusive.  I especially doubtful you
can have the kernel map the software interrupt table exclusively.  But
again, I don't really know what I'm talking about here.  :)

>  Or is there a better way to take the bytes
>  out of service?

  My understanding is that it is possible to tell the kernel to
consider certain memory regions as reserved, using the kernel boot
parameter "memmap=".  For you, I think it would be:

	memmap=64$1

But again, given that the RAM in question has special meaning, I'm not
sure that will be effective.

>  The memory test from the SuSE 9.3 installation CD reports 5 memory errors at this
>  location in 250 passes (90 hours of testing).  The same testing program reports no
>  errors on a Thinkpad T60 after 138 test passes through 5 times more RAM, so it does
>  not appear to be imagining the defect.

  The fact that a test works on one machine and not another isn't
necessarily conclusive.  I've encountered hardware that appears to
have features incompatible with MemTest86, where some region of memory
will always be identified as "bad", even though the memory is in fact
fine.  The fact that the fault is reported intermittently is a sign
that it is an accurate diagnostic, though.  Design features are
usually consistent.

  Still, I would suggest obtaining the latest version of the Dell
Diagnostics for your computer from the Dell website, and running that.
 (I think that generation of laptop will have them as images of a
mutli-diskette boot set.)  Sometimes the OEM diagnostics know things
generic diagnostics don't.  At the very least, it would be nice if
both MemTest86 and Dell Diags identify the same spot as bad.  :)

-- Ben


More information about the gnhlug-discuss mailing list