To: "Chris Friesen" <cfriesen@nortel.com>
Cc: Arjan van de Ven <arjan@infradead.org>, linux-kernel@vger.kernel.org,
       Doug Thompson <norsk5@yahoo.com>, <linux-mm@kvack.org>,
       <bluesmoke-devel@lists.sourceforge.net>
Subject: Re: marching through all physical memory in software
References: <497DD8E5.1040305@nortel.com>
	<20090126075957.69b64a2e@infradead.org> <497F5289.404@nortel.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Tue, 27 Jan 2009 12:16:52 -0800
In-Reply-To: <497F5289.404@nortel.com> (Chris Friesen's message of "Tue\, 27 Jan 2009 12\:29\:29 -0600")
Message-ID: <m1vds0bj2j.fsf@fess.ebiederm.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1177
Lines: 33

"Chris Friesen" <cfriesen@nortel.com> writes:

> Arjan van de Ven wrote:
>> On Mon, 26 Jan 2009 09:38:13 -0600
>> "Chris Friesen" <cfriesen@nortel.com> wrote:
>>
>>> Someone is asking me about the feasability of "scrubbing" system
>>> memory by accessing each page and handling the ECC faults.
>>>
>>
>> Hi,
>>
>> I would suggest that you look at the "edac" subsystem, which tries to
>> do exactly this....


> edac appears to currently be able to scrub the specific page where the fault
> occurred.  This is a useful building block, but doesn't provide the ability to
> march through all of physical memory.

Well that is the tricky part.  The rest is simply finding which physical
addresses are valid.  Either by querying the memory controller or looking
at the range the BIOS gave us.

That part should not be too hard.  I think it simply has not been implemented
yet as most ECC chipsets implement this in hardware today.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/