Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758855Ab1FVUap (ORCPT <rfc822;w@1wt.eu>);
	Wed, 22 Jun 2011 16:30:45 -0400
Received: from app1b.xlhost.de ([213.202.242.162]:52988 "EHLO app1b.xlhost.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1758081Ab1FVUao (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 22 Jun 2011 16:30:44 -0400
Message-ID: <4E0250F2.2010607@kpanic.de>
Date: Wed, 22 Jun 2011 22:30:42 +0200
From: Stefan Assmann <sassmann@kpanic.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10
MIME-Version: 1.0
To: "H. Peter Anvin" <hpa@zytor.com>
CC: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        akpm@linux-foundation.org, tony.luck@intel.com, andi@firstfloor.org,
        mingo@elte.hu, rick@vanrein.org, rdunlap@xenotime.net
Subject: Re: [PATCH v2 0/3] support for broken memory modules (BadRAM)
References: <1308741534-6846-1-git-send-email-sassmann@kpanic.de> <4E023142.1080605@zytor.com>
In-Reply-To: <4E023142.1080605@zytor.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1640
Lines: 35

On 22.06.2011 20:15, H. Peter Anvin wrote:
> On 06/22/2011 04:18 AM, Stefan Assmann wrote:
>>
>> The idea is to allow the user to specify RAM addresses that shouldn't be
>> touched by the OS, because they are broken in some way. Not all machines have
>> hardware support for hwpoison, ECC RAM, etc, so here's a solution that allows to
>> use bitmasks to mask address patterns with the new "badram" kernel command line
>> parameter.
>> Memtest86 has an option to generate these patterns since v2.3 so the only thing
>> for the user to do should be:
>> - run Memtest86
>> - note down the pattern
>> - add badram=<pattern> to the kernel command line
>>
> 
> We already support the equivalent functionality with
> memmap=<address>$<length> for those with only a few ranges... this has
> been supported for ages, literally.  For those with a lot of ranges,
> like Google, the command line is insufficient.

Right, I think this has been discussed a while ago. So the advantages I
see in this approach are. It allows to break down memory exclusion to
the page level with a pattern of non-consecutive pages. So if every
other page would be considered bad that's a bit tough to deal with using
memmap.
Secondly patterns can be easily generated by running Memtest86 and thus
easily be fed to the kernel by command line. Making it much more feasible
for the average user to take advantage of it.

  Stefan
--
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/