Re: Memory tester for powerpc?
Tuomas Kuosmanen writes:
> On Fri, 2002-01-25 at 07:06, Michel Lanners wrote:
>> On 25 Jan, this message from Russell Hires echoed through cyberspace:
>>> Just so I can be sure it's not my RAM causing my kernel oopses,
>>> is there a utility for testing RAM in Linux? I know that there
>>> is one in the x86 world that can test memory, but in the powerpc
>>> world...???
...
> http://www.qcc.sk.ca/~charlesc/software/memtester/
>
> This one runs on ppc. I cannot tell if it is good or bad, since I dont
> know how a memory test should work to be "good", but it prints nice
> stats to STDOUT, hogs the CPU and allocates a lot of RAM. I guess it
> works ;-)
It's hopeless. It does indeed hog the CPU and eat RAM though.
The first problems spotted:
has useless tests that are slow
does not report physical or kernel addresses
does not cover all memory
You need physical addresses if you'd like to use the bad RAM
with the affected pages avoided.
> I wonder how hard it would be to port memtest86 to ppc, it is a neat one
> since it is basically a linux kernel that just runs the memory test.
> Nice way to minimize the reserved memory size.. But I guess it also
> writes its output directly to the VGA memory, which would be a problem
> for PPC I guess.
That's a half-way reasonable idea. Doing a straight port won't
work due to memtest86 being x86 assembly, but copying the idea
would be good.
Due to the damn framebuffer, a ppc memory tester will need to
carry along a good sized chunk of the kernel. With memtest86,
only the Linux boot code is used.
I'm thinking that a memory tester could be an in-kernel process.
It grabs a huge contiguous chunk of memory, tests it, frees it,
and then allows a normal boot to proceed. At some point the
memory tester might move the kernel's physical location, keeping
the virtual location unchanged by adjusting the BAT mappings as
needed. (must not forget USB writing to memory, etc.)
So this tests pretty much everything, including the low memory
if one doesn't mind testing with interrupts off for a while.
Results are easy to save, since the fully-booted system will
have them in /proc.
Another nice thing about doing it this way is that the tester
can enable/disable the cache like memtest86 does.
Reply to: