From: David Newall <david@davidnewall.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Richard D <richard@embunus.com>,
"'Matthew Bloch'" <matthew@bytemark.co.uk>,
linux-kernel@vger.kernel.org
Subject: Re: Testing RAM from userspace / question about memmap= arguments
Date: Sun, 23 Dec 2007 02:36:14 +1030 [thread overview]
Message-ID: <476D35F6.90900@davidnewall.com> (raw)
In-Reply-To: <20071222134612.GA4098@ucw.cz>
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. If there is
something wrong with memtest86, doing the tests from within Linux is not
the answer. The answer is to fix memtest86. If the problem is that you
automation, e.g. switching a server from production to memory test mode
at midnight and back again at 6am, the answer is still to "fix"
memtest86. Writing something that grabs some physical RAM from Linux's
control, tests it, and then moves the kernel itself so that it can test
the rest, is adding a whole extra layer of complexity to an already
challenging (I assume, based on errors that dedicated software-based
testers miss) problem.
Give up on this misguided idea and build on the best tools that are
already available.
next prev parent reply other threads:[~2007-12-22 16:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-18 17:06 Testing RAM from userspace / question about memmap= arguments Matthew Bloch
2007-12-20 12:33 ` Jon Masters
2007-12-20 14:17 ` Matthew Bloch
2007-12-21 12:58 ` Pavel Machek
2007-12-22 8:12 ` Richard D
2007-12-22 13:46 ` Pavel Machek
2007-12-22 15:30 ` Richard D
2007-12-22 18:43 ` Pavel Machek
2007-12-22 16:06 ` David Newall [this message]
2007-12-22 18:47 ` Pavel Machek
2007-12-22 20:36 ` David Newall
2007-12-22 20:54 ` Pavel Machek
2007-12-23 7:35 ` David Newall
2007-12-23 11:17 ` Pavel Machek
2007-12-22 20:48 ` Matthew Bloch
2007-12-22 20:09 ` Arjan van de Ven
2007-12-25 23:09 ` Pavel Machek
2007-12-26 10:17 ` Arjan van de Ven
2007-12-26 20:37 ` Maxim Levitsky
-- strict thread matches above, loose matches on Subject: below --
2007-12-20 17:01 Siva Prasad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=476D35F6.90900@davidnewall.com \
--to=david@davidnewall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@bytemark.co.uk \
--cc=pavel@ucw.cz \
--cc=richard@embunus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.