Re: Testing RAM from userspace / question about memmap= arguments

[Matthew Bloch <matthew@bytemark.co.uk>]

David Newall wrote:
> Pavel Machek wrote:
>> On Sat 2007-12-22 13:42:47, Richard D wrote:
>>  
>>> Cant you, modify bootmem allocator to test with memtest patterns and 
>>> then
>>> use kexec (as Pavel suggested) to test the one where kernel was sitting
>>> earlier?
>>>     
>>
>>
>> I do not think you need to modify anything in kernel. Just use
>> /dev/mem to test areas that kernel doesn't see, then kexec into place
>> you already tested, and test the rest.
>>   
> 
> That's still an insufficient test.  One failure mode is writes at one 
> location corrupting cells at another.
> 
> The idea of wanting to do comprehensive and robust memory testing from 
> within the operating system seems dubious at best, to me.  

Well if we're trying to be thorough, either way is flawed - you can't 
possibly test pathologically-misbehaving memory from code running from 
inside of it, you'd want some kind of non-uniform memory arrangement to 
do that properly.  memtest86's value is that it at least *tries* to work 
in this environment by dynamically relocating itself, but its memory 
testing algorithms aren't the hard bit.  Also I'm not necessarily 
interested in *which* section of which DIMM is faulty, just a yes or no 
is enough so I can send the faulty ones back to the shop.

I don't agree that adding a network stack to memtest86's bare kernel is 
going to be easier than working out how to get Linux to do the same job, 
with its luxurious programming environment.  I can already automate 
memtest via serial consoles, power cycling, network booting and so on 
but it's ugly.

I will report back in the new year when I've had a chance to play with 
our collection of dodgy hardware.

-- 
Matthew