RAM Mapping Script
Jim Kuzdrall
gnhlug at intrel.com
Sun Mar 2 10:40:19 EST 2008
On Sunday 02 March 2008 09:18, Kevin D. Clark wrote:
> Jim Kuzdrall writes:
> > The error occurs at address 64h. 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.
>
> You're a little bit between a rock and a hard place here. From your
> description, the memory location of the bad RAM is in a very low
> memory location. The Linux kernel doesn't use this memory; it leaves
> this memory alone for the BIOS to do its Power On Self Test (POST).
>
> So this memory isn't even available to be reserved; the Linux kernel
> isn't even interacting with it in the first place.
>
> Is there any way in your BIOS to perform a more extensive POST, or to
> mark this memory as being bad?
There is only one level of self-check in this BIOS and that is
enabled.
The (bad) behavior of the system does not point to a BIOS problem,
however. 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.
What do you think of this theory? The BIOS unpacks its startup code
into low RAM, but then allows that to be overwritten. The ROM itself
is mapped outside of the allowed RAM range, where it makes the
interrupt table and low-level drivers available. After startup, it
would seem that the BIOS based programs would not need any RAM.
If Linux uses the low memory range for the kernel stack, the
behavior would be explained by a bad bit (and it is only one bit) in
the stack. (The Intel products build stack from low to high memory, if
I remember correctly.)
How would one try to map-out the low memory byte to see how Linux
responded to the try?
Jim Kuzdrall
More information about the gnhlug-discuss
mailing list