lkml.org 
[lkml]   [2007]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Testing RAM from userspace / question about memmap= arguments
Pavel Machek wrote:
> On Sun 2007-12-23 07:06:58, David Newall wrote:
>
>> It's kind of hard to run anything over SSH if it has to be run before
>> userspace is up. But the kernel can collect results from a modified
>> memtest, after it chains back.
>>
>
> memtest can be ran from userspace, that's the point.
>

I'm not sure I believe that. You need to tinker with hardware tables
before you know what physical RAM is being used. Sequential virtual
pages might be mapped to sequential physical RAM, but it might also be
mapped psuedo-randomly, or even page-reverse-sequential! How can you do
a basic walking bit test when you could be accessing pages in random order?

>>> 1) if linux fixes some problem with PCI quirk or microcod
>>> upload, memtest will not see the fix
>>>
>>>
>> What are you saying? Linux is going to fix faulty RAM?
>>
>
> Yes, that's what CPU microcode update is for. And I want to test my
> RAM with up-to-date microcode.
>

Don't microcode updates fix CPU bugs? That's not fixing faulty RAM. If
base microcode is so faulty as to make RAM access unreliable, the CPU
probably won't even POST, let alone boot the kernel and start a whole
bunch of userspace stuff, before it can get around to checking to see if
there is new microcode for that CPU and download it.

I suppose a CPU retains microcode updates, once loaded, until power-down
or some hard reboot that you surely can avoid. If it does happen that
you have an update that works around something unrelated to the CPU, for
example maybe interaction with a bridge, then you can update the CPU
before running memtest. Once loaded it's there until power down.

>> These are not RAM faults. The very last thing you want is evidence that
>> you've got a faulty piece of RAM when the fault is actually a hard disk
>> glitch!
>>
>
> No, it may be power supply leading to RAM problems. Yes, I want to
> detect that.

I'm sure you don't mean that. I'm sure you don't want a faulty power
supply to look like faulty RAM. No amount of replacing pieces of memory
is going to solve a faulty power supply. At worst you'll hit on a
combination of pieces that pass the test ... and then the system will
fail, mysteriously, in production. I'm certain you don't want that.

Anyhow, good luck with your idea. I think it's crazy, and that you're
doomed to failure. Doomed! I tell you.


\
 
 \ /
  Last update: 2007-12-23 08:39    [W:0.038 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site