Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[devzero]

> > >What is wrong with mem=exactmap?
> > 
> > probably no ordinary user knows how to use it instead of badram?
> > http://lists.opensuse.org/opensuse/2007-04/msg00501.html
> > 
> > someone please show us how to use that instead of badram or how this 
> > can replace what badram does.
> 
> as i said it in another reply to this thread, it would be perfectly 

sorry, but maybe that reply was sent off-list ? at least i cannot find that in the archive...

> acceptable for upstream to merge an easier to use boot option - be that 
> badmem=addr$size or excludemem=addr$size. Please send a patch :-)
> 
> 	Ingo

easier to use option? isn`t badram meant to be used together with memtest86 and 
isn`t that patterns generated by memtest86 already meant to provide a highly efficient way 
to specify bad memory regions ? i don`t see where there is room for optimization here. 
see that slightly outdate linuxjournal article at http://www.linuxjournal.com/article/4489  
or the "Capturing errors in a pattern" chapter inside the patch.

regards
roland

_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

V4 with checkpatch.pl done ...



Start of Documentation for BadRAM/memmap - 
Reference: http://lkml.org/lkml/2008/3/2/42

Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>


diff -up /dev/null bad-memory.txt
--- /dev/null   2007-09-21 21:12:45.000000000 +0200
+++ bad-memory.txt      2008-03-11 18:44:45.101344820 +0100
@@ -0,0 +1,56 @@
+March 2008
+Jan-Simon Moeller, dl9pf@gmx.de
+
+
+How to deal with bad memory e.g. reported by memtest86+ ?
+#########################################################
+
+There are three possibilities I know of:
+
+1) Reinsert/swap the memory modules
+
+2) Buy new modules (best!) or try to exchange the memory
+   if you have spare-parts
+
+3) Use BadRAM or memmap
+
+This Howto is about number 3) .
+
+
+BadRAM
+######
+BadRAM is the actively developed and available as kernel-patch
+here:  http://rick.vanrein.org/linux/badram/
+
+It takes the patterns of memtest86+ as arguments to exclude the defective
+areas of the memory.
+
+Example: memtest86+ reported here errors at address 0x18691458, 0x18698424 and
+         some others. All had 0x1869xxxx in common, so I chose a pattern of
+         0x18690000,0xffff0000.
+         This means exclusion of the area from 0x18690000 to 0x1869ffff
+         (which is a block of 64k).
+         My kernel-cmdline was:  badram=0x18690000,0xffff0000
+
+There are efforts to bring BadRAM into mainline in some way, possibly using
+memmap internally (maybe 2.6.26 ?).
+Thread on lkml: http://lkml.org/lkml/2008/3/2/42
+
+For more details see the BadRAM documentation.
+
+
+memmap
+######
+memmap is already in the kernel and usable as kernel-parameter at boot-time.
+Its syntax is different and you may need to calculate the values by yourself!
+
+Syntax to exclude a memory area (see kernel-parameters.txt for details):
+memmap=<size>$<address>
+
+With the numbers of the example above:
+memmap=64K$0x18690000
+ or
+memmap=0x10000$0x18690000
+
+TODO: Multiple areas to exclude using memmap ?
+








Add example of usage to memmap - evolved from thread about BadRAM inclusion.

Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>


diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 533e67f..f25da88 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1131,6 +1131,10 @@ and is between 256 and 4096 characters. It is defined in the file
 	memmap=nn[KMG]$ss[KMG]
 			[KNL,ACPI] Mark specific memory as reserved.
 			Region of memory to be used, from ss to ss+nn.
+			Example: Exclude memory from 0x18690000-0x1869ffff
+			         memmap=64K$0x18690000
+			         or
+			         memmap=0x10000$0x18690000
 
 	meye.*=		[HW] Set MotionEye Camera parameters
 			See Documentation/video4linux/meye.txt.

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Johannes Weiner]

Hi Jan-Simon,

Jan-Simon Möller <dl9pf@gmx.de> writes:

> Patches V3 with corrected Syntax, tnx hpa !
> Changed also text according to idea from Len.
>
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 533e67f..f25da88 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1131,6 +1131,10 @@ and is between 256 and 4096 characters. It is defined 
> in the file
>         memmap=nn[KMG]$ss[KMG]
>                         [KNL,ACPI] Mark specific memory as reserved.
>                         Region of memory to be used, from ss to ss+nn.
> +                       Example: Exclude memory from 0x18690000-0x1869ffff
> +                                memmap=64K$0x18690000
> +                                or
> +                                memmap=0x10000$0x18690000
>
>         meye.*=         [HW] Set MotionEye Camera parameters
>                         See Documentation/video4linux/meye.txt.
>
>
> Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>

Would you mind formatting the patch as described in
Documentation/SubmittingPatches?  That probably increases the chance of
getting it merged.

As far as your patch is concerned, I see broken whitespace, a changelog
entry and the signed-off-by is in the wrong place.

	Hannes

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

Patches V3 with corrected Syntax, tnx hpa !
Changed also text according to idea from Len.

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 533e67f..f25da88 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1131,6 +1131,10 @@ and is between 256 and 4096 characters. It is defined 
in the file
        memmap=nn[KMG]$ss[KMG]
                        [KNL,ACPI] Mark specific memory as reserved.
                        Region of memory to be used, from ss to ss+nn.
+                       Example: Exclude memory from 0x18690000-0x1869ffff
+                                memmap=64K$0x18690000
+                                or
+                                memmap=0x10000$0x18690000

        meye.*=         [HW] Set MotionEye Camera parameters
                        See Documentation/video4linux/meye.txt.


Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>



--- /dev/null   2007-09-21 21:12:45.000000000 +0200
+++ bad-memory.txt      2008-03-11 18:44:45.101344820 +0100
@@ -0,0 +1,56 @@
+March 2008
+Jan-Simon Moeller, dl9pf@gmx.de
+
+
+How to deal with bad memory e.g. reported by memtest86+ ?
+#########################################################
+
+There are three possibilities I know of:
+
+1) Reinsert/swap the memory modules (bad contact?)
+
+2) Buy new modules (best!) or try to exchange the memory
+   if you have spare-parts
+
+3) Use BadRAM or memmap
+
+This Howto is about number 3) .
+
+
+BadRAM
+######
+BadRAM is the actively developed and available as kernel-patch
+here:  http://rick.vanrein.org/linux/badram/
+
+It takes the patterns of memtest86+ as arguments to exclude the defective
+areas of the memory.
+
+Example: memtest86+ reported here errors at address 0x18691458, 0x18698424 
and
+         some others. All had 0x1869xxxx in common, so I chose a pattern of
+         0x18690000,0xffff0000.
+         This means exclusion of the area from 0x18690000 to 0x1869ffff
+         (which is a block of 64k).
+         My kernel-cmdline was:  badram=0x18690000,0xffff0000
+
+There are efforts to bring BadRAM into mainline in some way, possibly using
+memmap internally (maybe 2.6.26 ?).
+Thread on lkml: http://lkml.org/lkml/2008/3/2/42
+
+For more details see the BadRAM documentation.
+
+
+memmap
+######
+memmap is already in the kernel and usable as kernel-parameter at boot-time.
+Its syntax is different and you may need to calculate the values by yourself!
+
+Syntax to exclude a memory area (see kernel-parameters for details):
+memmap=<size>$<address>
+
+With the numbers of the example above:
+memmap=64K$0x18690000
+ or
+memmap=0x10000$0x18690000
+
+TODO: Multiple areas to exclude using memmap ?
+


Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Len Brown]

> +How to deal with bad memory e.g. reported by memtest86+ ?
> +#########################################################
> +
> +There are three possibilities I know of:

I find that sometimes memory problems go away when
I simply remove and then re-insert the same DIMMs.
Maybe that is the thing to try first.

-Len

> +1) Buy new memory (best!)
> +
> +2) Try to exchange the memory if you have spare-parts
> +
> +3) Use BadRAM or memmap
> +
> +This Howto is about number 3) .

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[H. Peter Anvin]

Jan-Simon Möller wrote:
> Am Montag 10 März 2008 18:20:19 schrieb H. Peter Anvin:
>> Jan-Simon Möller wrote:
>>> badram=0x18690000,0xffff0000
>>> (which means a whole from 0x18690000 to 0x1869ffff )
>> memmap=0x18690000$64K
>>
>> 	or
>>
>> memmap=0x18690000$0x10000
>>
>> 	-hpa
> 
> 
> Hmmm reading the kernel-parameters again and again ...
> 
> <QUOTE>
>         memmap=nn[KMG]$ss[KMG]
>                         [KNL,ACPI] Mark specific memory as reserved.
>                         Region of memory to be used, from ss to ss+nn.
> </QUOTE>
> 
> 
> nn would be 0x18690000   or ~409MB
> ss would be 0x10000      or 64k
> 
> quite big hole ???
> 
> I'm not in front of the faulty box, but something is wrong there ...
> 

Sorry, got it backwards.

	-hpa

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

Am Montag 10 März 2008 18:20:19 schrieb H. Peter Anvin:
> Jan-Simon Möller wrote:
> > badram=0x18690000,0xffff0000
> > (which means a whole from 0x18690000 to 0x1869ffff )
>
> memmap=0x18690000$64K
>
> 	or
>
> memmap=0x18690000$0x10000
>
> 	-hpa


Hmmm reading the kernel-parameters again and again ...

<QUOTE>
        memmap=nn[KMG]$ss[KMG]
                        [KNL,ACPI] Mark specific memory as reserved.
                        Region of memory to be used, from ss to ss+nn.
</QUOTE>


nn would be 0x18690000   or ~409MB
ss would be 0x10000      or 64k

quite big hole ???

I'm not in front of the faulty box, but something is wrong there ...

Best regards,
Jan-Simon

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

Patches V2

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 533e67f..e81f9da 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1131,6 +1131,10 @@ and is between 256 and 4096 characters. It is defined 
in the file
        memmap=nn[KMG]$ss[KMG]
                        [KNL,ACPI] Mark specific memory as reserved.
                        Region of memory to be used, from ss to ss+nn.
+                       Example: Exclude memory from 0x18690000-0x1869ffff
+                                memmap=0x18690000$64K
+                                or
+                                memmap=0x18690000$0x10000

        meye.*=         [HW] Set MotionEye Camera parameters
                        See Documentation/video4linux/meye.txt.


Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>




diff -Naur /dev/null bad-memory.txt
--- /dev/null   2007-09-21 21:12:45.000000000 +0200
+++ bad-memory.txt      2008-03-11 01:33:13.885991216 +0100
@@ -0,0 +1,55 @@
+March 2008
+Jan-Simon Moeller, dl9pf@gmx.de
+
+
+How to deal with bad memory e.g. reported by memtest86+ ?
+#########################################################
+
+There are three possibilities I know of:
+
+1) Buy new memory (best!)
+
+2) Try to exchange the memory if you have spare-parts
+
+3) Use BadRAM or memmap
+
+This Howto is about number 3) .
+
+
+BadRAM
+######
+BadRAM is the actively developed and available as kernel-patch
+here:  http://rick.vanrein.org/linux/badram/
+
+It takes the patterns of memtest86+ as arguments to exclude the defective
+areas of the memory.
+
+Example: memtest86+ reported here errors at address 0x18691458, 0x18698424 
and
+         some others. All had 0x1869xxxx in common, so I chose a pattern of
+         0x18690000,0xffff0000.
+         This means exclusion of the area from 0x18690000 to 0x1869ffff
+         (which is a block of 64k).
+         My kernel-cmdline was:  badram=0x18690000,0xffff0000
+
+There are efforts to bring BadRAM into mainline in some way, possibly using
+memmap internally (maybe 2.6.26 ?).
+Thread on lkml: http://lkml.org/lkml/2008/3/2/42
+
+For more details see the BadRAM documentation.
+
+
+memmap
+######
+memmap is already in the kernel and usable as kernel-parameter at boot-time.
+Its syntax is different and you may need to calculate the values by yourself!
+
+Syntax to exclude a memory area (see kernel-parameters for details):
+memmap=<address>$<size>
+
+With the numbers of the example above:
+memmap=0x18690000$64K
+ or
+memmap=0x18690000$0x10000
+
+TODO: Multiple areas to exclude using memmap ?
+

Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Pavel Machek]

Hi!

> What about ...

Thanks for doing this.

> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 533e67f..19343e1 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1131,6 +1131,10 @@ and is between 256 and 4096 characters. It is defined 
> in the file
>         memmap=nn[KMG]$ss[KMG]
>                         [KNL,ACPI] Mark specific memory as reserved.
>                         Region of memory to be used, from ss to ss+nn.
> +                       Example: Exclude memory from 0x18690000-0x1869ffff
> +                                memmap=0x18690000$64K
> +                                or
> +                                memmap=0x18690000$10000

missing 0x after $.


> diff --git a/Documentation/bad-memory.txt b/Documentation/bad-memory.txt
> new file mode 100644
> index 0000000..53e817d
> --- /dev/null
> +++ b/Documentation/bad-memory.txt
> @@ -0,0 +1,55 @@
> +March 2007
> +Jan-Simon Moeller, dl9pf@gmx.de
> +
> +
> +How to deal with bad memory e.g. reported by memtest86+ ?
> +#########################################################
> +
> +There are three possibilities I know of:
> +
> +1) Buy new memory (best!)
> +
> +2) Try to exchange the memory if you have spare-parts
> +
> +3) Use BadRAM or memmap
> +
> +This Howto is about number 3) .
> +
> +
> +BadRAM
> +######
> +BadRAM is actively developed and available as kernel-patch
> +here:  http://rick.vanrein.org/linux/badram/
> +
> +It takes the patterns of memtest86+ as arguments to exclude the defective
> +areas of the memory.
> +
> +Example: memtest86+ reported here errors at address 0x18691458, 0x18698424 
> and
> +         some others. All had 0x1869xxxx in common, so I chose a pattern of
> +         0x18690000,0xffff0000.
> +         This means exclusion of the area from 0x18690000 to 0x1869ffff
> +         (which is a block of 64k).
> +         My kernel-cmdline was:  badram=0x18690000,0xffff0000
> +
> +There are efforts to bring BadRAM into mainline in some way, possibly using
> +memmap internally (maybe for 2.6.26 ?).
> +Thread on lkml: http://lkml.org/lkml/2008/3/2/42
> +
> +For more details see the BadRAM documentation.
> +
> +
> +memmap
> +######
> +memmap is already in the kernel and usable as kernel-parameter at boot-time.
> +Its syntax is different and you may need to calculate the values by yourself!
> +
> +Syntax to exclude a memory area (see kernel-parameters for details):
> +memmap=<address>$<size>
> +
> +With the numbers of the example above:
> +memmap=0x18690000$64K
> + or
> +memmap=0x18690000$0x10000
> +
> +TODO: Multiple areas to exclude using memmap ?
> +
> 
> Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>

Actually, I'd include both..  I guess you should fix the 0x, the year,
and submit it to akpm (or trivial?).
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Rick van Rein]

Hello,

> >badram=0x18690000,0xffff0000
> >(which means a whole from 0x18690000 to 0x1869ffff )
> 
> memmap=0x18690000$64K
> 
> 	or
> 
> memmap=0x18690000$0x10000

The true challenge, of course, is to map things like these:

badram=0x18fedcba36,0xfffecff6a

This is a repetitive pattern, and this is why people enjoy the syntactic
sugar of BadRAM (which is penciled down from the output of memtest86).
It appears to be the prevailing wind in this discussion that the patch
must be rewritting to make series of amandments as a long series of
memmap would do, and I'll take on that task.

Cheers,
 -Rick

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

Am Montag 10 März 2008 19:59:46 schrieb Jan-Simon Möller:
> +March 2007

hmmm, change that to 2k8 !

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

What about ...

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 533e67f..19343e1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1131,6 +1131,10 @@ and is between 256 and 4096 characters. It is defined 
in the file
        memmap=nn[KMG]$ss[KMG]
                        [KNL,ACPI] Mark specific memory as reserved.
                        Region of memory to be used, from ss to ss+nn.
+                       Example: Exclude memory from 0x18690000-0x1869ffff
+                                memmap=0x18690000$64K
+                                or
+                                memmap=0x18690000$10000

        meye.*=         [HW] Set MotionEye Camera parameters
                        See Documentation/video4linux/meye.txt.

Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>




... and/or ...


diff --git a/Documentation/bad-memory.txt b/Documentation/bad-memory.txt
new file mode 100644
index 0000000..53e817d
--- /dev/null
+++ b/Documentation/bad-memory.txt
@@ -0,0 +1,55 @@
+March 2007
+Jan-Simon Moeller, dl9pf@gmx.de
+
+
+How to deal with bad memory e.g. reported by memtest86+ ?
+#########################################################
+
+There are three possibilities I know of:
+
+1) Buy new memory (best!)
+
+2) Try to exchange the memory if you have spare-parts
+
+3) Use BadRAM or memmap
+
+This Howto is about number 3) .
+
+
+BadRAM
+######
+BadRAM is actively developed and available as kernel-patch
+here:  http://rick.vanrein.org/linux/badram/
+
+It takes the patterns of memtest86+ as arguments to exclude the defective
+areas of the memory.
+
+Example: memtest86+ reported here errors at address 0x18691458, 0x18698424 
and
+         some others. All had 0x1869xxxx in common, so I chose a pattern of
+         0x18690000,0xffff0000.
+         This means exclusion of the area from 0x18690000 to 0x1869ffff
+         (which is a block of 64k).
+         My kernel-cmdline was:  badram=0x18690000,0xffff0000
+
+There are efforts to bring BadRAM into mainline in some way, possibly using
+memmap internally (maybe for 2.6.26 ?).
+Thread on lkml: http://lkml.org/lkml/2008/3/2/42
+
+For more details see the BadRAM documentation.
+
+
+memmap
+######
+memmap is already in the kernel and usable as kernel-parameter at boot-time.
+Its syntax is different and you may need to calculate the values by yourself!
+
+Syntax to exclude a memory area (see kernel-parameters for details):
+memmap=<address>$<size>
+
+With the numbers of the example above:
+memmap=0x18690000$64K
+ or
+memmap=0x18690000$0x10000
+
+TODO: Multiple areas to exclude using memmap ?
+

Signed-off-by: Jan-Simon Moeller <dl9pf@gmx.de>

Best regards,
Jan-Simon

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

Am Montag 10 März 2008 18:20:19 schrieb H. Peter Anvin:
> Jan-Simon Möller wrote:
> > badram=0x18690000,0xffff0000
> > (which means a whole from 0x18690000 to 0x1869ffff )
>
> memmap=0x18690000$64K
>
> 	or
>
> memmap=0x18690000$0x10000
>
> 	-hpa

Thanks a lot ! 

I'll reply with a patch for the Documentation and add an example.

Best regards,
Jan-Simon

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[H. Peter Anvin]

Jan-Simon Möller wrote:
> 
> badram=0x18690000,0xffff0000
> (which means a whole from 0x18690000 to 0x1869ffff )
> 

memmap=0x18690000$64K

	or

memmap=0x18690000$0x10000

	-hpa

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

Am Montag 10 März 2008 12:52:37 schrieb Pavel Machek:
> On Mon 2008-03-10 12:24:06, Jan-Simon Möller wrote:
> > Am Montag 10 März 2008 11:14:48 schrieben Sie:
> > > Feel free to improve memmap documentation.
> >
> > BUT ...
> > to do that, I would need to know already a bit of memmap ?!
> >
> > This is a Chicken-egg-problem !
> >
> > And I won't "waste" my time if i've a solution at hand already ?!
>
> ...so you waste everyone elses...?

This is no fair answer, Pavel - I already invested my time to find a solution 
and only found BadRAM at that time. So my impression is that for memmap 
there's so little doc that no average user is able to use it. This will also 
prevent users from making "derived" documentation for other use-cases. And 
again we're back to the chicken-egg ??
You can have the "nicest" solution out there - as long as its 
either "nasty-to-use" or zero-documented, no one will really use it.

> > Lets do it like this: Show me what i need to know about the usage of
> > memmap and i'll write some doc.
> >
> > Just shouting "write your own doc" is pointless, as I don't know this
> > part of the kernel myself (yet).
>
> Read the thread you are replying to. It was already there.

I did that and also read kernel-parameters.txt / memory.txt :
But there is _NO_ example line, just the synopsis. 
Do you expect all users to know what's e820 table is ? - this is not 
realistic. Not everybody is an expert in computer science.

Thats why BadRAM is used out there - memtest prints the values and BadRam can 
use them.

Lets try to get an example and document it:
My starting point would be: i wanna exclude this memory-area

badram=0x18690000,0xffff0000
(which means a whole from 0x18690000 to 0x1869ffff )

what would that be in memmap= -Syntax if i've got 2GB RAM in total ?

Best regards
Jan-Simon

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Pavel Machek]

On Mon 2008-03-10 12:24:06, Jan-Simon Möller wrote:
> Am Montag 10 März 2008 11:14:48 schrieben Sie:
> >
> > Feel free to improve memmap documentation.
> 
> 
> BUT ...
> to do that, I would need to know already a bit of memmap ?!
> 
> This is a Chicken-egg-problem ! 
> 
> And I won't "waste" my time if i've a solution at hand already ?!

...so you waste everyone elses...?

> Lets do it like this: Show me what i need to know about the usage of memmap 
> and i'll write some doc. 
> 
> Just shouting "write your own doc" is pointless, as I don't know this part of 
> the kernel myself (yet).

Read the thread you are replying to. It was already there.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

Am Montag 10 März 2008 11:14:48 schrieben Sie:
>
> Feel free to improve memmap documentation.
> 									Pavel


BUT ...
to do that, I would need to know already a bit of memmap ?!

This is a Chicken-egg-problem ! 

And I won't "waste" my time if i've a solution at hand already ?!

Lets do it like this: Show me what i need to know about the usage of memmap 
and i'll write some doc. 

Just shouting "write your own doc" is pointless, as I don't know this part of 
the kernel myself (yet).

Best regards
Jan-Simon

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jan-Simon Möller]

Am Samstag 08 März 2008 12:13:01 schrieb Jiri Kosina:
> On Sat, 8 Mar 2008, H. Peter Anvin wrote:
> > > as i said it in another reply to this thread, it would be perfectly
> > > acceptable for upstream to merge an easier to use boot option - be
> > > that badmem=addr$size or excludemem=addr$size. Please send a patch :-)
> >
> > It already called:
> > 	memmap=addr$size
> > ... and has been implemented for years.  Does the badram patch do
> > anything different?  (And yes, I agree the $/@/# is ugly.)
>
> I admit that I haven't examined badram too closely, but I think that what
> it has in addition to what you can get by simple 'memmap=..' is that it
> allows you to use bitmasks to mask particular address patterns.

I had once a bad ram-module and even after heavy search didn't came across 
memmap or its usage. Together with memtest86 badram= is pretty usable.
So for usability's sake i strongly vote for badram=  - good name, quite good 
to use. If you wanna tune on the internal implementation - thats fine ;) .

Best regards
Jan-Simon

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Jiri Kosina]

On Sat, 8 Mar 2008, H. Peter Anvin wrote:

> > as i said it in another reply to this thread, it would be perfectly 
> > acceptable for upstream to merge an easier to use boot option - be 
> > that badmem=addr$size or excludemem=addr$size. Please send a patch :-)
> It already called:
> 	memmap=addr$size
> ... and has been implemented for years.  Does the badram patch do anything
> different?  (And yes, I agree the $/@/# is ugly.)

I admit that I haven't examined badram too closely, but I think that what 
it has in addition to what you can get by simple 'memmap=..' is that it 
allows you to use bitmasks to mask particular address patterns.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[H. Peter Anvin]

H. Peter Anvin wrote:
> 
> More importantly:
> 
>     memmap=<size>$<len>
> 
> already allows you to knock arbitrary holes in the memory map.
> 

Sorry for the repeats.  I just came off a long flight and didn't 
remember I had already responded to this thread.

	-hpa

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[H. Peter Anvin]

Ingo Molnar wrote:
> * devzero@web.de <devzero@web.de> wrote:
> 
>>> What is wrong with mem=exactmap?
>> probably no ordinary user knows how to use it instead of badram?
>> http://lists.opensuse.org/opensuse/2007-04/msg00501.html
>>
>> someone please show us how to use that instead of badram or how this 
>> can replace what badram does.
> 
> as i said it in another reply to this thread, it would be perfectly 
> acceptable for upstream to merge an easier to use boot option - be that 
> badmem=addr$size or excludemem=addr$size. Please send a patch :-)
> 

It already called:

	memmap=addr$size


... and has been implemented for years.  Does the badram patch do 
anything different?  (And yes, I agree the $/@/# is ugly.)

	-hpa

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[H. Peter Anvin]

KOSAKI Motohiro wrote:
> Hi!
> 
>>  > This is the latest version of the BadRAM patch, which makes it possible to
>>  > run Linux on broken memory.  The patch supports the use of a lesser grade
>>  > of memory, which could be marketed more cheaply and which would thereby
>>  > decrease the environmental stress caused by the process of (memory) chip
>>  > manufacturing.
>>
>>  What is wrong with mem=exactmap?
> 
> Agghh,
> I had forgotten that.
> 
> you are right, may be.

More importantly:

	memmap=<size>$<len>

already allows you to knock arbitrary holes in the memory map.

	-hpa

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Ingo Molnar]

* H. Peter Anvin <hpa@zytor.com> wrote:

>>>>
>>> How is this different from:
>>>
>>> 	memmap=<size>$<len>
>>>
>>> ... ?
>>
>> it's the inverse? When we identify bad areas of RAM, we really want to 
>> "punch holes" into the existing memory map. So 'badram=' or 'excludemem=' 
>> would be nicer and easier to use.
>>
>> Or extend 'memmap=' with an inverse parameter: memmap=!0x10000000$1M would 
>> exclude a 1MB region at 256MB physical.
>>
>
> My understanding is that the $-form (as opposed to the @-form or 
> #-form) is exactly that:
>
>         memmap=nn[KMG]$ss[KMG]
>                         [KNL,ACPI] Mark specific memory as reserved.
>                         Region of memory to be used, from ss to ss+nn.
>
> "Reserved" usually means "don't use as either memory or free address 
> space".

ah - thanks - didnt know that!

i guess there might still be badram syntax details that might be worth 
merging, but "memmap=" looks a lot more complete than what i thought it 
to be.

	Ingo

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[H. Peter Anvin]

Ingo Molnar wrote:
>>>
>> How is this different from:
>>
>> 	memmap=<size>$<len>
>>
>> ... ?
> 
> it's the inverse? When we identify bad areas of RAM, we really want to 
> "punch holes" into the existing memory map. So 'badram=' or 
> 'excludemem=' would be nicer and easier to use.
> 
> Or extend 'memmap=' with an inverse parameter: memmap=!0x10000000$1M 
> would exclude a 1MB region at 256MB physical.
> 

My understanding is that the $-form (as opposed to the @-form or #-form) 
is exactly that:

         memmap=nn[KMG]$ss[KMG]
                         [KNL,ACPI] Mark specific memory as reserved.
                         Region of memory to be used, from ss to ss+nn.

"Reserved" usually means "don't use as either memory or free address space".

	-hpa

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Pavel Machek]

> > Please send a patch :-)
> 
> I've been reluctant to quickly mend things because it could lead to
> unstable code.  The patch that I am presenting is mature code, with the
> possible exception of the somewhat newer 64-bit code.  If this list has
> a preference for less mature code that is hardly field-tested, I could
> of course tailor to that.

Clean/small/simple is preferable to 'has been stable for 7 years',
yes.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Ingo Molnar]

* Rick van Rein <rick@vanrein.org> wrote:

> > as i said it in another reply to this thread, it would be perfectly 
> > acceptable for upstream to merge an easier to use boot option - be 
> > that badmem=addr$size or excludemem=addr$size.
> 
> I'm not sure if that is an optimal replacement of BadRAM at all.
> 
> Broken memories usually manifest themselves as a column or row in a 
> DIMM that stopped working.  So there is a pattern in the memory that 
> is to be excluded, and I'm not wholly sure that combines well with the 
> excludemem mechanism.  (I will look into it to be sure.)  I hope to 
> know after the weekend if the patterns that I am talking about can be 
> turned into to a cosmetic boot option.

feel free to extend the "excludemem=" mechanism to support the full 
range of "badram=" configuration methods. As long as you are able to 
feed it into an e820 table (which is not trivial at all), it's the right 
thing to do and it would be mainstream acceptable.

and i wouldnt mind the "badmem=" option either - because you already 
have users of that facility and it's intuitively named as well - as long 
as it's cleanly fed into the e820 space. I.e. it would all look and 
behave the same way towards users as the BadMem patch does - with a 
different internal approach.

	Ingo

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Rick van Rein]

Ingo,

> as i said it in another reply to this thread, it would be perfectly 
> acceptable for upstream to merge an easier to use boot option - be that 
> badmem=addr$size or excludemem=addr$size.

I'm not sure if that is an optimal replacement of BadRAM at all.

Broken memories usually manifest themselves as a column or row in a DIMM
that stopped working.  So there is a pattern in the memory that is to be
excluded, and I'm not wholly sure that combines well with the excludemem
mechanism.  (I will look into it to be sure.)  I hope to know after the
weekend if the patterns that I am talking about can be turned into to a
cosmetic boot option.

I've also read that people on this list say that it is a waste to throw
out a full page if only 5 bytes (say) are actually faulty.  Although it
is certainly interesting from an academic viewpoint to avoid this, it has
never, ever led to complaints.  I've been advertising the possibility of
using the pages for allocation slabs, and allow all slabs except for those
with an error contained, but nobody has ever taken that seriously.

> Please send a patch :-)

I've been reluctant to quickly mend things because it could lead to
unstable code.  The patch that I am presenting is mature code, with the
possible exception of the somewhat newer 64-bit code.  If this list has
a preference for less mature code that is hardly field-tested, I could
of course tailor to that.


Cheers,

Rick van Rein

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Ingo Molnar]

* devzero@web.de <devzero@web.de> wrote:

> >What is wrong with mem=exactmap?
> 
> probably no ordinary user knows how to use it instead of badram?
> http://lists.opensuse.org/opensuse/2007-04/msg00501.html
> 
> someone please show us how to use that instead of badram or how this 
> can replace what badram does.

as i said it in another reply to this thread, it would be perfectly 
acceptable for upstream to merge an easier to use boot option - be that 
badmem=addr$size or excludemem=addr$size. Please send a patch :-)

	Ingo

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[devzero]

>What is wrong with mem=exactmap?

probably no ordinary user knows how to use it instead of badram?
http://lists.opensuse.org/opensuse/2007-04/msg00501.html

someone please show us how to use that instead of badram or how this can replace what badram does.

regards
roland 
______________________________________________________
Bis 50 MB Dateianhänge? Kein Problem!
http://freemail.web.de/club/landingpage.htm/?mc=025556

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Randy Dunlap]

On Sun, 2 Mar 2008 13:42:21 +0000 Rick van Rein wrote:

> This is the latest version of the BadRAM patch, which makes it possible to
> run Linux on broken memory.  The patch supports the use of a lesser grade
> of memory, which could be marketed more cheaply and which would thereby
> decrease the environmental stress caused by the process of (memory) chip
> manufacturing.

Patch needs to be made against (i.e., applyable against) the latest
linus-mainline kernel, not a few-weeks old kernel.
Of course, you could be lucky and it applies to either one.

> diff -pruN linux-2.6.24.orig/Documentation/badram.txt linux-2.6.24/Documentation/badram.txt
> --- linux-2.6.24.orig/Documentation/badram.txt	1969-12-31 19:00:00.000000000 -0500
> +++ linux-2.6.24/Documentation/badram.txt	2008-02-05 23:29:49.000000000 -0500
> @@ -0,0 +1,275 @@
> +INFORMATION ON USING BAD RAM MODULES
> +====================================
> +
> +
> +Initial checks
> +       If you experience RAM trouble, first read /usr/src/linux/memory.txt

Incorrect path.  Insert "Documentation/".  But we usually don't include
the full path (i.e., drop "/usr/src/linux" or say
"read Documentation/memory.txt in the kernel source tree".

> +       and try out the mem=4M trick to see if at least some initial parts
> +       of your RAM work well. The BadRAM routines halt the kernel in panic
> +       if the reserved area of memory (containing kernel stuff) contains
> +       a faulty address.
> +
> +Running a RAM checker
> +       The memory checker is not built into the kernel, to avoid delays at
> +       runtime. If you experience problems that may be caused by RAM, run
> +       a good RAM checker, such as
> +               http://reality.sgi.com/cbrady_denver/memtest86
> +       The output of a RAM checker provides addresses that went wrong. In
> +       the 32 MB chip with 512 faulty bits mentioned above, the errors were
> +       found in the 8MB-16MB range (the DIMM was in slot #0) at addresses
> +               xxx42f4
> +               xxx62f4
> +               xxxc2f4
> +               xxxe2f4
> +       and the error was a "sticky 1 bit", a memory bit that stayed "1" no
> +       matter what was written to it. The regularity of this pattern
> +       suggests the death of a buffer at the output stages of a row on one of
> +       the chips. I expect such regularity to be commonplace. Finding this
> +       regularity currently is human effort, but it should not be hard to
> +       alter a RAM checker to capture it in some sort of pattern, possibly
> +       the BadRAM patterns described below.
> +
> +       By the way, if you manage to get hold of memtest86 version 2.3 or
> +       beyond, you can configure the printing mode to produce BadRAM patterns,
> +       which find out exactly what you must enter on the LILO: commandline,

Drop ":".

> +       except that you shouldn't mention the added spacing. That means that
> +       you can skip the following step, which saves you a *lot* of work.
> +
> +       Also by the way, if your machine has the ISA memory gap in the 15M-16M
> +       range unstoppable, Linux can get in trouble. One way of handling that
> +       situation is by specifying the total memory size to Linux with a boot
> +       parameter mem=... and then to tell it to treat the 15M-16M range as
> +       faulty with an additional boot parameter, for instance:
> +               mem=24M badram=0x00f00000,0xfff00000
> +       if you installed 24MB of RAM in total.
> +
> +
> +Capturing errors in a pattern
> +       Instead of manually providing all 512 errors to the kernel, it's nicer
> +       to generate a pattern. Since the regularity is based on address decoding
> +       software, which generally takes certain bits into account and ignores
> +       others, we shall provide a faulty address F, together with a bit mask M
> +       that specifies which bits must be equal to F. In C code, an address A
> +       is faulty if and only if
> +               (F & M) == (A & M)
> +       or alternately (closer to a hardware implementation):
> +               ~((F ^ A) & M)
> +       In the example 32 MB chip, we had the faulty addresses in 8MB-16MB:
> +               xxx42f4         ....0100....
> +               xxx62f4         ....0110....
> +               xxxc2f4         ....1100....
> +               xxxe2f4         ....1110....
> +       The second column represents the alternating hex digit in binary form.
> +       Apperantly, the first and one-but last binary digit can be anything,

          Apparently
s/one-but last/next to last/ ?

> +       so the binary mask for that part is 0101. The mask for the part after
> +       this is 0xfff, and the part before should select anything in the range
> +       8MB-16MB, or 0x00800000-0x01000000; this is done with a bitmask
> +       0xff80xxxx. Combining these partial masks, we get:
> +               F=0x008042f4    M=0xff805fff
> +       That covers everything for this DIMM; for more complicated failing
> +       DIMMs, or for a combination of multiple failing DIMMs, it can be
> +       necessary to set up a number of such F/M pairs.
> +
> +Rebooting Linux
> +       Now that these patterns are known (and double-checked, the calculations
> +       are highly error-prone... it would be neat to test them in the RAM
> +       checker...) we simply restart Linux with these F/M pairs as a parameter

End above sentence with period (".").

> +       If you normally boot as follows:
> +              LILO: linux
> +       you should now boot with
> +              LILO: linux badram=0x008042f4,0xff805fff

Does the choice of bootloader matter?

> +       or perhaps by mentioning more F/M pairs in an order F0,M0,F1,M1,...
> +       When you provide an odd number of arguments to badram, the default mask
> +       0xffffffff (only one address matched) is applied to the pattern.
> +
> +       Beware of the commandline length. At least up to LILO version 0.21,
> +       the commandline is cut off after the 78th character; later versions
> +       may go as far as the kernel goes, namely 255 characters. In no way is
> +       it possible to enter more than 10 numbers to the badram boot option.

x86 command line length is now 2048.
I don't know if bootloaders can handle that.

> +       When the kernel now boots, it should not give any trouble with RAM.
> +       Mind you, this is under the assumption that the kernel and its data
> +       storage do not overlap an erroneous part. If this happens, and the
> +       kernel does not choke on it right away, it will stop with a panic.
> +       You will need to provide a RAM where the initial, say 2MB, is faultless

End with period (".").

> +
> +       Now look up your memory status with
> +              dmesg | grep ^Memory:
> +       which prints a single line with information like
> +               Memory: 158524k/163840k available
> +                       (940k kernel code,
> +                       412k reserved,
> +                       1856k data,
> +                       60k init,
> +                       0k highmem,
> +                       2048k BadRAM)

> +Known Bugs
> +       LILO is known to cut off commandlines which are too long. For the
> +       lilo-0.21 distribution, a commandline may not exceed 78 characters,
> +       while actually, 255 would be possible [on x86, kernel 2.2.16].

Ancient kernel alert.

> +       LILO does _not_ report too-long commandlines, but the error will
> +       show up as either a panic at boot time, stating
> +               panic: BadRAM page in initial area
> +       or the dmesg line starting with Memory: will mention an unpredicted
> +       number of kilobytes. (Note that the latter number only includes
> +       errors in accessed memory.)
> +
> +Future Possibilities
> +       It would be possible to use even more of the faulty RAMs by employing
> +       them for slabs. The smaller allocation granularity of slabs makes it
> +       possible to throw out just, say, 32 bytes surrounding an error. This
> +       would mean that the example DIMM only looses 16kB instead of 2MB.

                                                loses

> +       It might even be possible to allocate the slabs in such a way that,
> +       where possible, the remaining bytes in a slab structure are allocated
> +       around the error, reducing the RAM loss to 0 in the optimal situation!
> +
> +       However, this yield is somewhat faked: It is possible to provide 512
> +       pages of 32-byte slabs, but it is not certain that anyone would use
> +       that many 32-byte slabs at any time.
> +
> +       A better solution might be to alter the page allocation for a slab to
> +       have a preference for BadRAM pages, and given those a special treatment.
> +       This way, the BadRAM would be spread over all the slabs, which seems
> +       more likely to be a `true' pay-off. This would yield more overhead at
> +       slab allocation time, but on the other hand, by the nature of slabs,
> +       such allocations are made as rare as possible, so it might not matter
> +       that much. I am uncertain where to go.
> +
> +       Many suggestions have been made to insert a RAM checker at boot time;
> +       since this would leave the time to do only very meager checking, it
> +       is not a reasonable option; we already have a BIOS doing that in most
> +       systems!
> +
> +       It would be interesting to integrate this functionality with the
> +       self-verifying nature of ECC RAM. These memories can even distinguish
> +       between recorable and unrecoverable errors! Such memory has been

                  recoverable

> +       handled in older operating systems by `testing' once-failed memory
> +       blocks for a while, by placing only (reloadable) program code in it.
> +       Unfortunately, I possess no faulty ECC modules to work this out.
> +

> diff -pruN linux-2.6.24.orig/Documentation/kernel-parameters.txt linux-2.6.24/Documentation/kernel-parameters.txt
> --- linux-2.6.24.orig/Documentation/kernel-parameters.txt	2008-01-24 17:58:37.000000000 -0500
> +++ linux-2.6.24/Documentation/kernel-parameters.txt	2008-02-05 23:33:55.000000000 -0500
> @@ -322,6 +323,8 @@ and is between 256 and 4096 characters. 
>  
>  	autotest	[IA64]
>  
> +	badram=		[BADRAM] Avoid allocating faulty RAM addresses.

			See Documentation/badram.txt for parameter details.

> +
>  	baycom_epp=	[HW,AX25]
>  			Format: <io>,<mode>
>  
> diff -pruN linux-2.6.24.orig/Documentation/memory.txt linux-2.6.24/Documentation/memory.txt
> --- linux-2.6.24.orig/Documentation/memory.txt	2008-01-24 17:58:37.000000000 -0500
> +++ linux-2.6.24/Documentation/memory.txt	2008-02-05 23:39:04.000000000 -0500
> @@ -18,11 +18,22 @@ systems.
>  	   as you add more memory.  Consider exchanging your 
>             motherboard.
>  
> +	4) A static discharge or production fault causes a RAM module
> +	  to have (predictable) errors, usually meaning that certain
> +	  bits cannot be set or reset. Instead of throwing away your
> +	  RAM module, you may read /usr/src/linux/Documentation/badram.txt
> +	  to learn how to detect, locate and circuimvent such errors

                                             circumvent

> +	  in your RAM module.
> +
> +
> diff -pruN linux-2.6.24.orig/include/asm-x86/page_32.h linux-2.6.24/include/asm-x86/page_32.h
> --- linux-2.6.24.orig/include/asm-x86/page_32.h	2008-01-24 17:58:37.000000000 -0500
> +++ linux-2.6.24/include/asm-x86/page_32.h	2008-02-05 23:43:00.000000000 -0500
> @@ -189,6 +189,7 @@ extern int page_is_ram(unsigned long pag
>  #define pfn_valid(pfn)		((pfn) < max_mapnr)
>  #endif /* CONFIG_FLATMEM */
>  #define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> +#define phys_to_page(x)         pfn_to_page((unsigned long)(x) >> PAGE_SHIFT)

Use tab(s), not spaces.

>  
>  #define virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
>  
> diff -pruN linux-2.6.24.orig/include/asm-x86/page_64.h linux-2.6.24/include/asm-x86/page_64.h
> --- linux-2.6.24.orig/include/asm-x86/page_64.h	2008-01-24 17:58:37.000000000 -0500
> +++ linux-2.6.24/include/asm-x86/page_64.h	2008-02-05 23:44:26.000000000 -0500
> @@ -126,6 +126,7 @@ extern unsigned long __phys_addr(unsigne
>  #endif
>  
>  #define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> +#define phys_to_page(x)         pfn_to_page((unsigned long)(x) >> PAGE_SHIFT)

Ditto.

>  #define virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
>  #define pfn_to_kaddr(pfn)      __va((pfn) << PAGE_SHIFT)
>  
> diff -pruN linux-2.6.24.orig/mm/page_alloc.c linux-2.6.24/mm/page_alloc.c
> --- linux-2.6.24.orig/mm/page_alloc.c	2008-01-24 17:58:37.000000000 -0500
> +++ linux-2.6.24/mm/page_alloc.c	2008-02-06 00:03:28.000000000 -0500
> @@ -4378,6 +4381,91 @@ EXPORT_SYMBOL(pfn_to_page);
>  EXPORT_SYMBOL(page_to_pfn);
>  #endif /* CONFIG_OUT_OF_LINE_PFN_TO_PAGE */
>  
> +
> +#ifdef CONFIG_BADRAM
> +
> +
> +void __init badram_markpages (int argc, unsigned long *argv) {
> +       unsigned long addr, mask;
> +       while (argc-- > 0) {
> +               addr = *argv++;
> +               mask = (argc-- > 0) ? *argv++ : ~0L;
> +               mask |= ~PAGE_MASK;     /* Optimalisation */

                                             Optimisation ?

> +               addr &= mask;           /* Normalisation */
> +               do {
> +                       struct page *pg = phys_to_page(addr);
> +                       printk(KERN_DEBUG "%016lx =%016lx\n",
> +                                       addr >> PAGE_SHIFT,
> +                                       (unsigned long)(pg-mem_map));
> +                       if (PageTestandSetBad (pg))
> +                               reserve_bootmem (addr, PAGE_SIZE);
> +               } while (next_masked_address (&addr,mask));
> +       }
> +}
> +
> +
> +
> +static int __init badram_setup (char *str)
> +{
> +       unsigned long opts[3];
> +       BUG_ON(!mem_map);
> +       printk (KERN_INFO "PAGE_OFFSET=0x%08lx\n", PAGE_OFFSET);
> +       printk (KERN_INFO "BadRAM option is %s\n", str);

No space after function name (2x).

> +       if (*str++ == '=')
> +               while ((str = get_longoptions (str, 3, (long *) opts), *opts)) {
> +                       printk (KERN_INFO "   --> marking 0x%08lx, 0x%08lx  [%ld]\n",
> +                                       opts[1], opts[2], opts[0]);
> +                       badram_markpages (*opts, opts+1);
> +                       if (*opts == 1)
> +                               break;
> +               };
> +       badram_markpages (*badram_custom, badram_custom+1);
> +       return 0;
> +}


---
~Randy

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[KOSAKI Motohiro]

Hi!

>  > This is the latest version of the BadRAM patch, which makes it possible to
>  > run Linux on broken memory.  The patch supports the use of a lesser grade
>  > of memory, which could be marketed more cheaply and which would thereby
>  > decrease the environmental stress caused by the process of (memory) chip
>  > manufacturing.
>
>  What is wrong with mem=exactmap?

Agghh,
I had forgotten that.

you are right, may be.

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Pavel Machek]

Hi!

> This is the latest version of the BadRAM patch, which makes it possible to
> run Linux on broken memory.  The patch supports the use of a lesser grade
> of memory, which could be marketed more cheaply and which would thereby
> decrease the environmental stress caused by the process of (memory) chip
> manufacturing.

What is wrong with mem=exactmap?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[KAMEZAWA Hiroyuki]

On Mon, 3 Mar 2008 18:35:02 +1100
Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> On Monday 03 March 2008 18:14, KOSAKI Motohiro wrote:
> > > > some architecture use PG_reserved for treat bad memory.
> > > > Why do you want introduce new page flag?
> > > > for show_mem() improvement?
> > >
> > > I'd like to get rid of PG_reserved at some point. So I'd
> > > rather not overload it with more meanings ;)
> >
> > really?
> >
> > as far as I know, IA64 already use PG_reserved for bad memory.
> > please see arch/ia64/kernel/mcs_drv.c#mca_page_isolate.
> >
> > Doesn't it works on ia64 if your patch introduce?
> 
> It doesn't really need to use PG_reserved there, no. It could
> use PG_bad for that instead.
> 
Hmm, it seems that it's necessary to rewrite ia64/mca code after PG_bad
patch is merged.

Thanks,
-Kame

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[KOSAKI Motohiro]

> > as far as I know, IA64 already use PG_reserved for bad memory.
> > please see arch/ia64/kernel/mcs_drv.c#mca_page_isolate.
> >
> > Doesn't it works on ia64 if your patch introduce?
> 
> It doesn't really need to use PG_reserved there, no. It could
> use PG_bad for that instead.

unfortunately that feature already merged to mainline.
and i am not its developer, sorry ;)

- kosaki

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Nick Piggin]

On Monday 03 March 2008 18:14, KOSAKI Motohiro wrote:
> > > some architecture use PG_reserved for treat bad memory.
> > > Why do you want introduce new page flag?
> > > for show_mem() improvement?
> >
> > I'd like to get rid of PG_reserved at some point. So I'd
> > rather not overload it with more meanings ;)
>
> really?
>
> as far as I know, IA64 already use PG_reserved for bad memory.
> please see arch/ia64/kernel/mcs_drv.c#mca_page_isolate.
>
> Doesn't it works on ia64 if your patch introduce?

It doesn't really need to use PG_reserved there, no. It could
use PG_bad for that instead.

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[KOSAKI Motohiro]

> > some architecture use PG_reserved for treat bad memory.
> > Why do you want introduce new page flag?
> > for show_mem() improvement?
> 
> I'd like to get rid of PG_reserved at some point. So I'd
> rather not overload it with more meanings ;)

really?

as far as I know, IA64 already use PG_reserved for bad memory.
please see arch/ia64/kernel/mcs_drv.c#mca_page_isolate.

Doesn't it works on ia64 if your patch introduce?


- kosaki

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Nick Piggin]

On Monday 03 March 2008 04:01, KOSAKI Motohiro wrote:
> Hi
>
> in general,
> Agreed with we need bad memory treatness.
>
> >  +#define PG_badram              20      /* BadRam page */
>
> some architecture use PG_reserved for treat bad memory.
> Why do you want introduce new page flag?
> for show_mem() improvement?

I'd like to get rid of PG_reserved at some point. So I'd
rather not overload it with more meanings ;)

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[KOSAKI Motohiro]

Hi Rick

> > >  +#define PG_badram              20      /* BadRam page */
> > 
> > some architecture use PG_reserved for treat bad memory.
> > Why do you want introduce new page flag?
> 
> It is clearer to properly name a flag, I suppose.
> Is the use that you are mentioning the intended, and only use of the flag?
> If not, I think it is clearer to use a separate flag instead of overloading
> one.

hmmm
unfortunately flag bit of struct page is very valuable resource
rather than diamond on current implementaion ;-)

if you can change to no introduce new page flag,
IMHO merge to mainline dramatically become easy.


> > for show_mem() improvement?
> 
> For code clarity.

agreed with your code is clarify. but...

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Rick van Rein]

Hello,

> This is a great feature for those of us who value their money more
> than a few hours of time as well.  :-)

That's how it's most often used, indeed.  I do value the environmental
aspect as well: the potential for memory manufacturers (say, for the
$100 laptop) to ship out their broken memories at a low cost, thereby
delivering more products for a given amount of toxic waste created in
the chip etching process.

> I would very much like to see this patch in mainline

Many, many people want to.  I've been asked about it a lot, but always
lacked the time to figure out how.

> ISTR that one
> argument that has been historically made against this sort of thing is
> that it would make bug reports unreliable.

Actually it's broken memory that makes reports unreliable, not the patch :)

After the right set of broken addresses has been applied, the whole system
runs as reliably as any other system.  And I hope people have the wits to
mistrust a system for a while after they've plugged in broken DIMMs ;-)

> mechanism now, so that shouldn't be a showstopper -- if that's the
> only argument, then set a new taint flag, please.

I doubt that'll be necessary, but yes, it'd be a way out.  Thanks.

Cheers,
 -Rick

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Joseph Fannin]

On Sun, Mar 02, 2008 at 01:42:21PM +0000, Rick van Rein wrote:
> This is the latest version of the BadRAM patch, which makes it possible to
> run Linux on broken memory.  The patch supports the use of a lesser grade
> of memory, which could be marketed more cheaply and which would thereby
> decrease the environmental stress caused by the process of (memory) chip
> manufacturing.
>
> Over the years, feedback on this patch has invariably been positive and
> enthousiastic.  The patch, even though not part of mainstream Linux, still
> managed to make lots of people happy:
>  - schools and other low-budget computer users
>  - people with partially defective RAM soldered onto laptop motherboards
>  - people with one faulty address due to wiring faults on their motherboard
>  - people who find it environmentally insane to toss out 99.99%-good hardware
>
> The patch has been well-maintained over the years, mostly by volunteers
> who keep track of kernel updates.  The submitters have changed over the years,
> but there have always been volunteers jumping in, sometimes within hours after
> a new kernel appeared, and mostly within a day.  I have processed support
> requests and used them to learn and make the patch work optimally.  It is
> obvious to me that the patch is in good demand, and I think it earns to be
> included in the mainstream kernel.
>
> The current version supports ia32 and x86_64 architectures.  Others would
> be unpractical to add on a patch outside mainstream Linux, but it ought to
> be straightforward to add support for other architectures as well.
>
> For more information, read Documentation/badram.txt or visit the homepage
> for the patch, http://rick.vanrein.org/linux/badram/

This is a great feature for those of us who value their money more
than a few hours of time as well.  :-)

I would very much like to see this patch in mainline -- I've used it
to allow use of a marginally bad RAM stick in my home
workstation/fileserver, with great results (i.e. my FS never went
belly-up).

There have been times when I was reluctant to report bugs in a BadMEM
patched kernel, due to the patching, as well as times when I would
have liked to have stuck with my distro's kernel, but couldn't, 'cause
I needed to patch BadRAM in.

I haven't used BadRAM in a minute, nor read the patch.  ISTR that one
argument that has been historically made against this sort of thing is
that it would make bug reports unreliable.  But we have the taint
mechanism now, so that shouldn't be a showstopper -- if that's the
only argument, then set a new taint flag, please.

I've added a akpm to the CC list.

--
Joseph Fannin
jfannin@gmail.com

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[Rick van Rein]

Hello Kosaki,

> in general,
> Agreed with we need bad memory treatness.

Glad to hear that.

> >  +#define PG_badram              20      /* BadRam page */
> 
> some architecture use PG_reserved for treat bad memory.
> Why do you want introduce new page flag?

It is clearer to properly name a flag, I suppose.
Is the use that you are mentioning the intended, and only use of the flag?
If not, I think it is clearer to use a separate flag instead of overloading
one.

> for show_mem() improvement?

For code clarity.


Thanks,
 -Rick

Re: [PATCH 2.6.24] mm: BadRAM support for broken memory

[KOSAKI Motohiro]

Hi

in general,
Agreed with we need bad memory treatness.

>  +#define PG_badram              20      /* BadRam page */

some architecture use PG_reserved for treat bad memory.
Why do you want introduce new page flag?
for show_mem() improvement?

[PATCH 2.6.24] mm: BadRAM support for broken memory

[Rick van Rein]

This is the latest version of the BadRAM patch, which makes it possible to
run Linux on broken memory.  The patch supports the use of a lesser grade
of memory, which could be marketed more cheaply and which would thereby
decrease the environmental stress caused by the process of (memory) chip
manufacturing.

Over the years, feedback on this patch has invariably been positive and
enthousiastic.  The patch, even though not part of mainstream Linux, still
managed to make lots of people happy:
 - schools and other low-budget computer users
 - people with partially defective RAM soldered onto laptop motherboards
 - people with one faulty address due to wiring faults on their motherboard
 - people who find it environmentally insane to toss out 99.99%-good hardware

The patch has been well-maintained over the years, mostly by volunteers
who keep track of kernel updates.  The submitters have changed over the years,
but there have always been volunteers jumping in, sometimes within hours after
a new kernel appeared, and mostly within a day.  I have processed support
requests and used them to learn and make the patch work optimally.  It is
obvious to me that the patch is in good demand, and I think it earns to be
included in the mainstream kernel.

The current version supports ia32 and x86_64 architectures.  Others would
be unpractical to add on a patch outside mainstream Linux, but it ought to
be straightforward to add support for other architectures as well.

For more information, read Documentation/badram.txt or visit the homepage
for the patch, http://rick.vanrein.org/linux/badram/

Signed-off-by: Rick van Rein <rick@vanrein.org>

diff -pruN linux-2.6.24.orig/arch/x86/configs/i386_defconfig linux-2.6.24/arch/x86/configs/i386_defconfig
--- linux-2.6.24.orig/arch/x86/configs/i386_defconfig	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/arch/x86/configs/i386_defconfig	2008-02-05 22:18:57.000000000 -0500
@@ -198,6 +198,7 @@ CONFIG_DMIID=y
 # CONFIG_NOHIGHMEM is not set
 CONFIG_HIGHMEM4G=y
 # CONFIG_HIGHMEM64G is not set
+CONFIG_BADRAM=y
 CONFIG_PAGE_OFFSET=0xC0000000
 CONFIG_HIGHMEM=y
 CONFIG_ARCH_POPULATES_NODE_MAP=y
diff -pruN linux-2.6.24.orig/arch/x86/configs/x86_64_defconfig linux-2.6.24/arch/x86/configs/x86_64_defconfig
--- linux-2.6.24.orig/arch/x86/configs/x86_64_defconfig	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/arch/x86/configs/x86_64_defconfig	2008-02-05 23:15:17.000000000 -0500
@@ -132,6 +132,7 @@ CONFIG_X86_CPUID=y
 CONFIG_X86_HT=y
 CONFIG_X86_IO_APIC=y
 CONFIG_X86_LOCAL_APIC=y
+CONFIG_BADRAM=y
 CONFIG_MTRR=y
 CONFIG_SMP=y
 CONFIG_SCHED_SMT=y
diff -pruN linux-2.6.24.orig/arch/x86/Kconfig linux-2.6.24/arch/x86/Kconfig
--- linux-2.6.24.orig/arch/x86/Kconfig	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/arch/x86/Kconfig	2008-02-05 22:52:33.000000000 -0500
@@ -813,6 +813,24 @@ config X86_PAE
 	  has the cost of more pagetable lookup overhead, and also
 	  consumes more pagetable space per process.
 
+
+config BADRAM
+	bool "Work around bad spots in RAM"
+	default y
+	help
+	  This small kernel extension makes it possible to use memory chips
+	  which are not entirely correct. It works by never allocating the
+	  places that are wrong. Those places are specified with the badram
+	  boot option to LILO. Read Documentation/badram.txt and/or visit
+	  http://home.zonnet.nl/vanrein/badram for information.
+
+	  This option co-operates well with a second boot option from LILO
+	  that starts memtest86, which is able to automatically produce the
+	  patterns for the commandline in case of memory trouble.
+
+	  It is safe to say 'Y' here, and it is advised because there is no
+	  performance impact.
+
 # Common NUMA Features
 config NUMA
 	bool "Numa Memory Allocation and Scheduler Support (EXPERIMENTAL)"
diff -pruN linux-2.6.24.orig/arch/x86/mm/init_32.c linux-2.6.24/arch/x86/mm/init_32.c
--- linux-2.6.24.orig/arch/x86/mm/init_32.c	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/arch/x86/mm/init_32.c	2008-02-05 23:10:33.000000000 -0500
@@ -275,25 +275,31 @@ static void __init permanent_kmaps_init(
 	pkmap_page_table = pte;	
 }
 
-static void __meminit free_new_highpage(struct page *page)
+static void __meminit free_new_highpage(struct page *page, int* bad)
 {
 	init_page_count(page);
-	__free_page(page);
+	if (PageBad(page))
+		*bad=1;
+	else
+		__free_page(page);
 	totalhigh_pages++;
 }
 
-void __init add_one_highpage_init(struct page *page, int pfn, int bad_ppro)
+void __init add_one_highpage_init(struct page *page, int pfn, int bad_ppro,
+		int* bad)
 {
+	*bad=0;
 	if (page_is_ram(pfn) && !(bad_ppro && page_kills_ppro(pfn))) {
 		ClearPageReserved(page);
-		free_new_highpage(page);
+		free_new_highpage(page, bad);
 	} else
 		SetPageReserved(page);
 }
 
 static int __meminit add_one_highpage_hotplug(struct page *page, unsigned long pfn)
 {
-	free_new_highpage(page);
+	int dummy;
+	free_new_highpage(page, &dummy);
 	totalram_pages++;
 #ifdef CONFIG_FLATMEM
 	max_mapnr = max(pfn, max_mapnr);
@@ -316,17 +322,21 @@ void __meminit online_page(struct page *
 
 
 #ifdef CONFIG_NUMA
-extern void set_highmem_pages_init(int);
+extern void set_highmem_pages_init(int bad_ppro, int* pbad);
 #else
-static void __init set_highmem_pages_init(int bad_ppro)
+static void __init set_highmem_pages_init(int bad_ppro, int* pbad)
 {
-	int pfn;
+	int pfn, bad;
 	for (pfn = highstart_pfn; pfn < highend_pfn; pfn++) {
 		/*
 		 * Holes under sparsemem might not have no mem_map[]:
 		 */
-		if (pfn_valid(pfn))
-			add_one_highpage_init(pfn_to_page(pfn), pfn, bad_ppro);
+		if (pfn_valid(pfn)){
+			add_one_highpage_init(pfn_to_page(pfn), pfn, bad_ppro,
+			&bad);
+			if(bad)
+				(*pbad)++;
+		}
 	}
 	totalram_pages += totalhigh_pages;
 }
@@ -335,7 +345,7 @@ static void __init set_highmem_pages_ini
 #else
 #define kmap_init() do { } while (0)
 #define permanent_kmaps_init(pgd_base) do { } while (0)
-#define set_highmem_pages_init(bad_ppro) do { } while (0)
+#define set_highmem_pages_init(bad_ppro, pbad) do { } while (0)
 #endif /* CONFIG_HIGHMEM */
 
 unsigned long long __PAGE_KERNEL = _PAGE_KERNEL;
@@ -625,7 +635,7 @@ static struct kcore_list kcore_mem, kcor
 void __init mem_init(void)
 {
 	extern int ppro_with_ram_bug(void);
-	int codesize, reservedpages, datasize, initsize;
+	int codesize, reservedpages, badpages, datasize, initsize;
 	int tmp;
 	int bad_ppro;
 
@@ -649,14 +659,18 @@ void __init mem_init(void)
 	totalram_pages += free_all_bootmem();
 
 	reservedpages = 0;
-	for (tmp = 0; tmp < max_low_pfn; tmp++)
+	badpages = 0;
+	for (tmp = 0; tmp < max_low_pfn; tmp++){
 		/*
-		 * Only count reserved RAM pages
+		 * Only count reserved and bad RAM pages
 		 */
 		if (page_is_ram(tmp) && PageReserved(pfn_to_page(tmp)))
 			reservedpages++;
+		if (page_is_ram(tmp) && PageBad(pfn_to_page(tmp)))
+			badpages++;
+	}
 
-	set_highmem_pages_init(bad_ppro);
+	set_highmem_pages_init(bad_ppro, &badpages);
 
 	codesize =  (unsigned long) &_etext - (unsigned long) &_text;
 	datasize =  (unsigned long) &_edata - (unsigned long) &_etext;
@@ -665,6 +679,18 @@ void __init mem_init(void)
 	kclist_add(&kcore_mem, __va(0), max_low_pfn << PAGE_SHIFT); 
 	kclist_add(&kcore_vmalloc, (void *)VMALLOC_START, 
 		   VMALLOC_END-VMALLOC_START);
+#ifdef CONFIG_BADRAM
+	printk(KERN_INFO "Memory: %luk/%luk available (%dk kernel code, %dk reserved, %dk data, %dk init, %ldk highmem, %dk BadRAM)\n",
+               (unsigned long) nr_free_pages() << (PAGE_SHIFT-10),
+               num_physpages << (PAGE_SHIFT-10),
+               codesize >> 10,
+               reservedpages << (PAGE_SHIFT-10),
+               datasize >> 10,
+               initsize >> 10,
+               (unsigned long) (totalhigh_pages << (PAGE_SHIFT-10)),
+               badpages << (PAGE_SHIFT-10)
+              );
+#else
 
 	printk(KERN_INFO "Memory: %luk/%luk available (%dk kernel code, %dk reserved, %dk data, %dk init, %ldk highmem)\n",
 		(unsigned long) nr_free_pages() << (PAGE_SHIFT-10),
@@ -675,6 +701,7 @@ void __init mem_init(void)
 		initsize >> 10,
 		(unsigned long) (totalhigh_pages << (PAGE_SHIFT-10))
 	       );
+#endif
 
 #if 1 /* double-sanity-check paranoia */
 	printk("virtual kernel memory layout:\n"
diff -pruN linux-2.6.24.orig/arch/x86/mm/init_64.c linux-2.6.24/arch/x86/mm/init_64.c
--- linux-2.6.24.orig/arch/x86/mm/init_64.c	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/arch/x86/mm/init_64.c	2008-02-05 23:18:27.000000000 -0500
@@ -63,7 +63,7 @@ DEFINE_PER_CPU(struct mmu_gather, mmu_ga
 
 void show_mem(void)
 {
-	long i, total = 0, reserved = 0;
+	long i, total = 0, reserved = 0, badram=0;
 	long shared = 0, cached = 0;
 	pg_data_t *pgdat;
 	struct page *page;
@@ -85,6 +85,8 @@ void show_mem(void)
 			total++;
 			if (PageReserved(page))
 				reserved++;
+			else if (PageBad(page))
+				badram++;
 			else if (PageSwapCache(page))
 				cached++;
 			else if (page_count(page))
@@ -93,6 +95,10 @@ void show_mem(void)
 	}
 	printk(KERN_INFO "%lu pages of RAM\n", total);
 	printk(KERN_INFO "%lu reserved pages\n",reserved);
+#ifdef CONFIG_BADRAM
+       printk(KERN_INFO "%lu pages of BadRAM\n",badram);
+#endif
+
 	printk(KERN_INFO "%lu pages shared\n",shared);
 	printk(KERN_INFO "%lu pages swap cached\n",cached);
 }
diff -pruN linux-2.6.24.orig/arch/x86/mm/pgtable_32.c linux-2.6.24/arch/x86/mm/pgtable_32.c
--- linux-2.6.24.orig/arch/x86/mm/pgtable_32.c	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/arch/x86/mm/pgtable_32.c	2008-02-05 23:14:12.000000000 -0500
@@ -26,7 +26,7 @@
 
 void show_mem(void)
 {
-	int total = 0, reserved = 0;
+	int total = 0, reserved = 0, badram = 0;
 	int shared = 0, cached = 0;
 	int highmem = 0;
 	struct page *page;
@@ -48,6 +48,8 @@ void show_mem(void)
 				highmem++;
 			if (PageReserved(page))
 				reserved++;
+			if (PageBad(page))
+				badram++;
 			else if (PageSwapCache(page))
 				cached++;
 			else if (page_count(page))
@@ -58,6 +60,9 @@ void show_mem(void)
 	printk(KERN_INFO "%d pages of RAM\n", total);
 	printk(KERN_INFO "%d pages of HIGHMEM\n", highmem);
 	printk(KERN_INFO "%d reserved pages\n", reserved);
+#ifdef CONFIG_BADRAM
+	printk(KERN_INFO "%d pages of badRAM\n", badram);
+#endif
 	printk(KERN_INFO "%d pages shared\n", shared);
 	printk(KERN_INFO "%d pages swap cached\n", cached);
 
diff -pruN linux-2.6.24.orig/CREDITS linux-2.6.24/CREDITS
--- linux-2.6.24.orig/CREDITS	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/CREDITS	2008-02-05 23:20:34.000000000 -0500
@@ -2840,6 +2840,16 @@ S: 6 Karen Drive
 S: Malvern, Pennsylvania 19355
 S: USA
 
+N: Rick van Rein
+E: rick@vanrein.org
+W: http://rick.vanrein.org/
+D: Memory, the BadRAM subsystem dealing with statically challanged RAM modules.
+S: Haarlebrink 5
+S: 7544 WP  Enschede
+S: The Netherlands
+P: 1024D/89754606  CD46 B5F2 E876 A5EE 9A85  1735 1411 A9C2 8975 4606
+
+
 N: Stefan Reinauer
 E: stepan@linux.de
 W: http://www.freiburg.linux.de/~stepan/
diff -pruN linux-2.6.24.orig/Documentation/badram.txt linux-2.6.24/Documentation/badram.txt
--- linux-2.6.24.orig/Documentation/badram.txt	1969-12-31 19:00:00.000000000 -0500
+++ linux-2.6.24/Documentation/badram.txt	2008-02-05 23:29:49.000000000 -0500
@@ -0,0 +1,275 @@
+INFORMATION ON USING BAD RAM MODULES
+====================================
+
+Introduction
+       RAM is getting smaller and smaller, and as a result, also more and more
+       vulnerable. This makes the manufacturing of hardware more expensive,
+       since an excessive amount of RAM chips must be discarded on account of
+       a single cell that is wrong. Similarly, static discharge may damage a
+       RAM module forever, which is usually remedied by replacing it
+       entirely.
+
+       This is not necessary, as the BadRAM code shows: By informing the Linux
+       kernel which addresses in a RAM are damaged, the kernel simply avoids
+       ever allocating such addresses but makes all the rest available.
+
+Reasons for this feature
+       There are many reasons why this kernel feature is useful:
+       - Chip manufacture is resource intensive; waste less and sleep better
+       - It's another chance to promote Linux as "the flexible OS"
+       - Some laptops have their RAM soldered in... and then it fails!
+       - It's plain cool ;-)
+
+Running example
+       To run this project, I was given two DIMMs, 32 MB each. One, that we
+       shall use as a running example in this text, contained 512 faulty bits,
+       spread over 1/4 of the address range in a regular pattern. Some tricks
+       with a RAM tester and a few binary calculations were sufficient to
+       write these faults down in 2 longword numbers.
+
+       The kernel recognised the correct number of pages with faults and did
+       not give them out for allocation. The allocation routines could
+       therefore progress as normally, without any adaption.
+       So, I gained 30 MB of DIMM which would otherwise have been thrown
+       away. After booting the kernel, the kernel behaved exactly as it
+       always had.
+
+Initial checks
+       If you experience RAM trouble, first read /usr/src/linux/memory.txt
+       and try out the mem=4M trick to see if at least some initial parts
+       of your RAM work well. The BadRAM routines halt the kernel in panic
+       if the reserved area of memory (containing kernel stuff) contains
+       a faulty address.
+
+Running a RAM checker
+       The memory checker is not built into the kernel, to avoid delays at
+       runtime. If you experience problems that may be caused by RAM, run
+       a good RAM checker, such as
+               http://reality.sgi.com/cbrady_denver/memtest86
+       The output of a RAM checker provides addresses that went wrong. In
+       the 32 MB chip with 512 faulty bits mentioned above, the errors were
+       found in the 8MB-16MB range (the DIMM was in slot #0) at addresses
+               xxx42f4
+               xxx62f4
+               xxxc2f4
+               xxxe2f4
+       and the error was a "sticky 1 bit", a memory bit that stayed "1" no
+       matter what was written to it. The regularity of this pattern
+       suggests the death of a buffer at the output stages of a row on one of
+       the chips. I expect such regularity to be commonplace. Finding this
+       regularity currently is human effort, but it should not be hard to
+       alter a RAM checker to capture it in some sort of pattern, possibly
+       the BadRAM patterns described below.
+
+       By the way, if you manage to get hold of memtest86 version 2.3 or
+       beyond, you can configure the printing mode to produce BadRAM patterns,
+       which find out exactly what you must enter on the LILO: commandline,
+       except that you shouldn't mention the added spacing. That means that
+       you can skip the following step, which saves you a *lot* of work.
+
+       Also by the way, if your machine has the ISA memory gap in the 15M-16M
+       range unstoppable, Linux can get in trouble. One way of handling that
+       situation is by specifying the total memory size to Linux with a boot
+       parameter mem=... and then to tell it to treat the 15M-16M range as
+       faulty with an additional boot parameter, for instance:
+               mem=24M badram=0x00f00000,0xfff00000
+       if you installed 24MB of RAM in total.
+
+       If you use this patch on an x86_64 architecture, your addresses are
+       twice as long.  Fill up with zeroes in the address and with f's in
+       the mask.  The latter example would thus become:
+               mem=24M badram=0x0000000000f00000,0xfffffffffff00000
+       The patch applies the changes to both x86 and x86_64 code bases
+       at the same time.  Patching but not compiling maps the entire
+       source tree at once, which makes more sense than splitting the
+       patch into an x86 and x86_64 branch, because those two branches
+       could not be applied at the same time because they would overlap.
+
+Capturing errors in a pattern
+       Instead of manually providing all 512 errors to the kernel, it's nicer
+       to generate a pattern. Since the regularity is based on address decoding
+       software, which generally takes certain bits into account and ignores
+       others, we shall provide a faulty address F, together with a bit mask M
+       that specifies which bits must be equal to F. In C code, an address A
+       is faulty if and only if
+               (F & M) == (A & M)
+       or alternately (closer to a hardware implementation):
+               ~((F ^ A) & M)
+       In the example 32 MB chip, we had the faulty addresses in 8MB-16MB:
+               xxx42f4         ....0100....
+               xxx62f4         ....0110....
+               xxxc2f4         ....1100....
+               xxxe2f4         ....1110....
+       The second column represents the alternating hex digit in binary form.
+       Apperantly, the first and one-but last binary digit can be anything,
+       so the binary mask for that part is 0101. The mask for the part after
+       this is 0xfff, and the part before should select anything in the range
+       8MB-16MB, or 0x00800000-0x01000000; this is done with a bitmask
+       0xff80xxxx. Combining these partial masks, we get:
+               F=0x008042f4    M=0xff805fff
+       That covers everything for this DIMM; for more complicated failing
+       DIMMs, or for a combination of multiple failing DIMMs, it can be
+       necessary to set up a number of such F/M pairs.
+
+Rebooting Linux
+       Now that these patterns are known (and double-checked, the calculations
+       are highly error-prone... it would be neat to test them in the RAM
+       checker...) we simply restart Linux with these F/M pairs as a parameter
+       If you normally boot as follows:
+              LILO: linux
+       you should now boot with
+              LILO: linux badram=0x008042f4,0xff805fff
+       or perhaps by mentioning more F/M pairs in an order F0,M0,F1,M1,...
+       When you provide an odd number of arguments to badram, the default mask
+       0xffffffff (only one address matched) is applied to the pattern.
+
+       Beware of the commandline length. At least up to LILO version 0.21,
+       the commandline is cut off after the 78th character; later versions
+       may go as far as the kernel goes, namely 255 characters. In no way is
+       it possible to enter more than 10 numbers to the badram boot option.
+
+       When the kernel now boots, it should not give any trouble with RAM.
+       Mind you, this is under the assumption that the kernel and its data
+       storage do not overlap an erroneous part. If this happens, and the
+       kernel does not choke on it right away, it will stop with a panic.
+       You will need to provide a RAM where the initial, say 2MB, is faultless
+
+       Now look up your memory status with
+              dmesg | grep ^Memory:
+       which prints a single line with information like
+               Memory: 158524k/163840k available
+                       (940k kernel code,
+                       412k reserved,
+                       1856k data,
+                       60k init,
+                       0k highmem,
+                       2048k BadRAM)
+       The latter entry, the badram, is 2048k to represent the loss of 2MB
+       of general purpose RAM due to the errors. Or, positively rephrased,
+       instead of throwing out 32MB as useless, you only throw out 2MB.
+
+       If the system is stable (try compiling a few kernels, and do a few
+       finds in / or so) you may add the boot parameter to /etc/lilo.conf
+       as a line to _all_ the kernels that handle this trouble with a line
+               append="badram=0x008042f4,0xff805fff"
+       after which you run "lilo".
+       Warning: Don't experiment with these settings on your only boot image.
+       If the BadRAM overlays kernel code, data, init, or other reserved
+       memory, the kernel will halt in panic. Try settings on a test boot
+       image first, and if you get a panic you should change the order of
+       your DIMMs [which may involve buying a new one just to be able to
+       change the order].
+
+       You are allowed to enter any number of BadRAM patterns in all the
+       places documented in this file. They will all apply. It is even
+       possible to mention several BadRAM patterns in a single place. The
+       completion of an odd number of arguments with the default mask is
+       done separately for each badram=... option.
+
+Kernel Customisation
+       Some people prefer to enter their badram patterns in the kernel, and
+       this is also possible. In mm/page_alloc.c there is an array of unsigned
+       long integers into which the parameters can be entered, prefixed with
+       the number of integers (twice the number of patterns). The array is
+       named badram_custom and it will be added to the BadRAM list whenever an
+       option 'badram' is provided on the commandline when booting, either
+       with or without additional patterns.
+
+       For the previous example, the code would become
+
+       static unsigned long __initdata badram_custom[] = {
+               2,      // Number of longwords that follow, as F/M pairs
+               0x008042f4L, 0xff805fffL,
+       };
+
+       Even on this place you may assume the default mask to be filled in
+       when you enter an odd number of longwords. Specify the number of
+       longwords to be 0 to avoid influence of this custom BadRAM list.
+
+BadRAM classification
+       This technique may start a lively market for "dead" RAM. It is important
+       to realise that some RAMs are more dead than others. So, instead of
+       just providing a RAM size, it is also important to know the BadRAM
+       class, which is defined as follows:
+
+               A BadRAM class N means that at most 2^N bytes have a problem,
+               and that all problems with the RAMs are persistent: They
+               are predictable and always show up.
+
+       The DIMM that serves as an example here was of class 9, since 512=2^9
+       errors were found. Higher classes are worse, "correct" RAM is of class
+       -1 (or even less, at your choice).
+       Class N also means that the bitmask for your chip (if there's just one,
+       that is) counts N bits "0" and it means that (if no faults fall in the
+       same page) an amount of 2^N*PAGESIZE memory is lost, in the example on
+       an x86 architecture that would be 2^9*4k=2MB, which accounts for the
+       initial claim of 30MB RAM gained with this DIMM.
+
+       Note that this scheme has deliberately been defined to be independent
+       of memory technology and of computer architecture.
+
+Known Bugs
+       LILO is known to cut off commandlines which are too long. For the
+       lilo-0.21 distribution, a commandline may not exceed 78 characters,
+       while actually, 255 would be possible [on x86, kernel 2.2.16].
+       LILO does _not_ report too-long commandlines, but the error will
+       show up as either a panic at boot time, stating
+               panic: BadRAM page in initial area
+       or the dmesg line starting with Memory: will mention an unpredicted
+       number of kilobytes. (Note that the latter number only includes
+       errors in accessed memory.)
+
+Future Possibilities
+       It would be possible to use even more of the faulty RAMs by employing
+       them for slabs. The smaller allocation granularity of slabs makes it
+       possible to throw out just, say, 32 bytes surrounding an error. This
+       would mean that the example DIMM only looses 16kB instead of 2MB.
+       It might even be possible to allocate the slabs in such a way that,
+       where possible, the remaining bytes in a slab structure are allocated
+       around the error, reducing the RAM loss to 0 in the optimal situation!
+
+       However, this yield is somewhat faked: It is possible to provide 512
+       pages of 32-byte slabs, but it is not certain that anyone would use
+       that many 32-byte slabs at any time.
+
+       A better solution might be to alter the page allocation for a slab to
+       have a preference for BadRAM pages, and given those a special treatment.
+       This way, the BadRAM would be spread over all the slabs, which seems
+       more likely to be a `true' pay-off. This would yield more overhead at
+       slab allocation time, but on the other hand, by the nature of slabs,
+       such allocations are made as rare as possible, so it might not matter
+       that much. I am uncertain where to go.
+
+       Many suggestions have been made to insert a RAM checker at boot time;
+       since this would leave the time to do only very meager checking, it
+       is not a reasonable option; we already have a BIOS doing that in most
+       systems!
+
+       It would be interesting to integrate this functionality with the
+       self-verifying nature of ECC RAM. These memories can even distinguish
+       between recorable and unrecoverable errors! Such memory has been
+       handled in older operating systems by `testing' once-failed memory
+       blocks for a while, by placing only (reloadable) program code in it.
+       Unfortunately, I possess no faulty ECC modules to work this out.
+
+Names and Places
+       The home page of this project is on
+               http://rick.vanrein.org/linux/badram
+       This page also links to Nico Schmoigl's experimental extensions to
+       this patch (with debugging and a few other fancy things).
+
+       In case you have experiences with the BadRAM software which differ from
+       the test reportings on that site, I hope you will mail me with that
+       new information.
+
+       The BadRAM project is an idea and implementation by
+               Rick van Rein
+               Haarlebrink 5
+               7544 WP  Enschede
+               The Netherlands
+               rick@vanrein.org
+       If you like it, a postcard would be much appreciated ;-)
+
+
+                                                              Enjoy,
+                                                               -Rick.
diff -pruN linux-2.6.24.orig/Documentation/kernel-parameters.txt linux-2.6.24/Documentation/kernel-parameters.txt
--- linux-2.6.24.orig/Documentation/kernel-parameters.txt	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/Documentation/kernel-parameters.txt	2008-02-05 23:33:55.000000000 -0500
@@ -35,6 +35,7 @@ parameter is applicable:
 	APIC	APIC support is enabled.
 	APM	Advanced Power Management support is enabled.
 	AX25	Appropriate AX.25 support is enabled.
+	BADRAM	Support for faulty RAM chips is enabled.
 	BLACKFIN Blackfin architecture is enabled.
 	DRM	Direct Rendering Management support is enabled.
 	EDD	BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -322,6 +323,8 @@ and is between 256 and 4096 characters. 
 
 	autotest	[IA64]
 
+	badram=		[BADRAM] Avoid allocating faulty RAM addresses.
+
 	baycom_epp=	[HW,AX25]
 			Format: <io>,<mode>
 
diff -pruN linux-2.6.24.orig/Documentation/memory.txt linux-2.6.24/Documentation/memory.txt
--- linux-2.6.24.orig/Documentation/memory.txt	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/Documentation/memory.txt	2008-02-05 23:39:04.000000000 -0500
@@ -18,11 +18,22 @@ systems.
 	   as you add more memory.  Consider exchanging your 
            motherboard.
 
+	4) A static discharge or production fault causes a RAM module
+	  to have (predictable) errors, usually meaning that certain
+	  bits cannot be set or reset. Instead of throwing away your
+	  RAM module, you may read /usr/src/linux/Documentation/badram.txt
+	  to learn how to detect, locate and circuimvent such errors
+	  in your RAM module.
+
+
+
 All of these problems can be addressed with the "mem=XXXM" boot option
 (where XXX is the size of RAM to use in megabytes).  
 It can also tell Linux to use less memory than is actually installed.
 If you use "mem=" on a machine with PCI, consider using "memmap=" to avoid
 physical address space collisions.
+If this helps, read Documentation/badram.txt to learn how to
+find and circumvent memory errors.
 
 See the documentation of your boot loader (LILO, loadlin, etc.) about
 how to pass options to the kernel.
diff -pruN linux-2.6.24.orig/include/asm-x86/page_32.h linux-2.6.24/include/asm-x86/page_32.h
--- linux-2.6.24.orig/include/asm-x86/page_32.h	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/include/asm-x86/page_32.h	2008-02-05 23:43:00.000000000 -0500
@@ -189,6 +189,7 @@ extern int page_is_ram(unsigned long pag
 #define pfn_valid(pfn)		((pfn) < max_mapnr)
 #endif /* CONFIG_FLATMEM */
 #define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
+#define phys_to_page(x)         pfn_to_page((unsigned long)(x) >> PAGE_SHIFT)
 
 #define virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
 
diff -pruN linux-2.6.24.orig/include/asm-x86/page_64.h linux-2.6.24/include/asm-x86/page_64.h
--- linux-2.6.24.orig/include/asm-x86/page_64.h	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/include/asm-x86/page_64.h	2008-02-05 23:44:26.000000000 -0500
@@ -126,6 +126,7 @@ extern unsigned long __phys_addr(unsigne
 #endif
 
 #define virt_to_page(kaddr)	pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
+#define phys_to_page(x)         pfn_to_page((unsigned long)(x) >> PAGE_SHIFT)
 #define virt_addr_valid(kaddr)	pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
 #define pfn_to_kaddr(pfn)      __va((pfn) << PAGE_SHIFT)
 
diff -pruN linux-2.6.24.orig/include/linux/kernel.h linux-2.6.24/include/linux/kernel.h
--- linux-2.6.24.orig/include/linux/kernel.h	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/include/linux/kernel.h	2008-02-05 23:45:34.000000000 -0500
@@ -164,6 +164,8 @@ extern int vsscanf(const char *, const c
 
 extern int get_option(char **str, int *pint);
 extern char *get_options(const char *str, int nints, int *ints);
+extern int get_longoption (char **str, long *plong);
+extern char *get_longoptions(const char *str, int nlongs, long *longs);
 extern unsigned long long memparse(char *ptr, char **retptr);
 
 extern int core_kernel_text(unsigned long addr);
diff -pruN linux-2.6.24.orig/include/linux/page-flags.h linux-2.6.24/include/linux/page-flags.h
--- linux-2.6.24.orig/include/linux/page-flags.h	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/include/linux/page-flags.h	2008-02-05 23:47:58.000000000 -0500
@@ -93,6 +93,9 @@
 /* PG_readahead is only used for file reads; PG_reclaim is only for writes */
 #define PG_readahead		PG_reclaim /* Reminder to do async read-ahead */
 
+#define PG_badram              20      /* BadRam page */
+
+
 /* PG_owner_priv_1 users should have descriptive aliases */
 #define PG_checked		PG_owner_priv_1 /* Used by some filesystems */
 #define PG_pinned		PG_owner_priv_1	/* Xen pinned pagetable */
@@ -108,6 +111,15 @@
 #define PG_uncached		31	/* Page has been mapped as uncached */
 #endif
 
+#ifdef CONFIG_BADRAM
+#define PageBad(page)          test_bit(PG_badram, &(page)->flags)
+#define PageSetBad(page)       set_bit(PG_badram, &(page)->flags)
+#define PageTestandSetBad(page)     test_and_set_bit(PG_badram, &(page)->flags)
+#else
+#define PageBad(page)          0
+#endif
+
+
 /*
  * Manipulation of page state flags
  */
diff -pruN linux-2.6.24.orig/lib/cmdline.c linux-2.6.24/lib/cmdline.c
--- linux-2.6.24.orig/lib/cmdline.c	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/lib/cmdline.c	2008-02-05 23:51:47.000000000 -0500
@@ -114,6 +114,70 @@ char *get_options(const char *str, int n
 }
 
 /**
+ *     get_longoption - Parse long from an option string
+ *     @str: option string
+ *     @plong: (output) long value parsed from @str
+ *
+ *     Read a long from an option string; if available accept a subsequent
+ *     comma as well.
+ *
+ *     Return values:
+ *     0 : no long in string
+ *     1 : long found, no subsequent comma
+ *     2 : long found including a subsequent comma
+ */
+
+int get_longoption (char **str, long *plong)
+{
+       char *cur = *str;
+
+       if (!cur || !(*cur))
+               return 0;
+       *plong = simple_strtol (cur, str, 0);
+       if (cur == *str)
+               return 0;
+       if (**str == ',') {
+               (*str)++;
+               return 2;
+       }
+
+       return 1;
+}
+
+/**
+ *     get_longoptions - Parse a string into a list of longs
+ *     @str: String to be parsed
+ *     @nlongs: size of long array
+ *     @longs: long array
+ *
+ *     This function parses a string containing a comma-separated
+ *     list of longs.  The parse halts when the array is
+ *     full, or when no more numbers can be retrieved from the
+ *     string.
+ *
+ *     Return value is the character in the string which caused
+ *     the parse to end (typically a null terminator, if @str is
+ *     completely parseable).
+ */
+
+char *get_longoptions(const char *str, int nlongs, long *longs)
+{
+       int res, i = 1;
+
+       while (i < nlongs) {
+               res = get_longoption ((char **)&str, longs + i);
+               if (res == 0)
+                       break;
+               i++;
+               if (res == 1)
+                       break;
+       }
+       longs[0] = i - 1;
+       return (char *)str;
+}
+
+
+/**
  *	memparse - parse a string with mem suffixes into a number
  *	@ptr: Where parse begins
  *	@retptr: (output) Pointer to next char after parse completes
@@ -151,3 +215,5 @@ unsigned long long memparse (char *ptr, 
 EXPORT_SYMBOL(memparse);
 EXPORT_SYMBOL(get_option);
 EXPORT_SYMBOL(get_options);
+EXPORT_SYMBOL(get_longoption);
+EXPORT_SYMBOL(get_longoptions);
diff -pruN linux-2.6.24.orig/mm/bootmem.c linux-2.6.24/mm/bootmem.c
--- linux-2.6.24.orig/mm/bootmem.c	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/mm/bootmem.c	2008-02-05 23:53:57.000000000 -0500
@@ -317,10 +317,12 @@ static unsigned long __init free_all_boo
 	pfn = PFN_DOWN(bdata->node_boot_start);
 	idx = bdata->node_low_pfn - pfn;
 	map = bdata->node_bootmem_map;
+#ifndef CONFIG_BADRAM /* no idea if this is really needed */
 	/* Check physaddr is O(LOG2(BITS_PER_LONG)) page aligned */
 	if (bdata->node_boot_start == 0 ||
 	    ffs(bdata->node_boot_start) - PAGE_SHIFT > ffs(BITS_PER_LONG))
 		gofast = 1;
+#endif
 	for (i = 0; i < idx; ) {
 		unsigned long v = ~map[i / BITS_PER_LONG];
 
diff -pruN linux-2.6.24.orig/mm/page_alloc.c linux-2.6.24/mm/page_alloc.c
--- linux-2.6.24.orig/mm/page_alloc.c	2008-01-24 17:58:37.000000000 -0500
+++ linux-2.6.24/mm/page_alloc.c	2008-02-06 00:03:28.000000000 -0500
@@ -10,6 +10,7 @@
  *  Reshaped it to be a zoned allocator, Ingo Molnar, Red Hat, 1999
  *  Discontiguous memory support, Kanoj Sarcar, SGI, Nov 1999
  *  Zone balancing, Kanoj Sarcar, SGI, Jan 2000
+ *  BadRAM handling, Rick van Rein, Feb 2001
  *  Per cpu hot/cold page lists, bulk allocation, Martin J. Bligh, Sept 2002
  *          (lots of bits borrowed from Ingo Molnar & Andrew Morton)
  */
@@ -540,9 +541,11 @@ static void __free_pages_ok(struct page 
 void fastcall __init __free_pages_bootmem(struct page *page, unsigned int order)
 {
 	if (order == 0) {
		__ClearPageReserved(page);
-		set_page_count(page, 0);
-		set_page_refcounted(page);
+		if(!PageBad(page)){
+			set_page_count(page, 0);
+			set_page_refcounted(page);
 		__free_page(page);
+		}
 	} else {
 		int loop;
@@ -4378,6 +4381,91 @@ EXPORT_SYMBOL(pfn_to_page);
 EXPORT_SYMBOL(page_to_pfn);
 #endif /* CONFIG_OUT_OF_LINE_PFN_TO_PAGE */
 
+
+#ifdef CONFIG_BADRAM
+
+/* Given a pointed-at address and a mask, increment the page so that the
+ * mask hides the increment. Return 0 if no increment is possible.
+ */
+static int __init next_masked_address (unsigned long *addrp, unsigned long mask)
+{
+       unsigned long inc=1;
+       unsigned long newval = *addrp;
+       while (inc & mask)
+               inc += inc;
+       while (inc != 0) {
+               newval += inc;
+               newval &= ~mask;
+               newval |= ((*addrp) & mask);
+               if (newval > *addrp) {
+                       *addrp = newval;
+                       return 1;
+               }
+               do {
+                       inc += inc;
+               } while (inc & ~mask);
+               while (inc & mask)
+                       inc += inc;
+       }
+       return 0;
+}
+
+
+void __init badram_markpages (int argc, unsigned long *argv) {
+       unsigned long addr, mask;
+       while (argc-- > 0) {
+               addr = *argv++;
+               mask = (argc-- > 0) ? *argv++ : ~0L;
+               mask |= ~PAGE_MASK;     /* Optimalisation */
+               addr &= mask;           /* Normalisation */
+               do {
+                       struct page *pg = phys_to_page(addr);
+                       printk(KERN_DEBUG "%016lx =%016lx\n",
+                                       addr >> PAGE_SHIFT,
+                                       (unsigned long)(pg-mem_map));
+                       if (PageTestandSetBad (pg))
+                               reserve_bootmem (addr, PAGE_SIZE);
+               } while (next_masked_address (&addr,mask));
+       }
+}
+
+
+/*********** CONFIG_BADRAM: CUSTOMISABLE SECTION STARTS HERE *****************/
+/* Enter your custom BadRAM patterns here as pairs of unsigned long integers. */
+/* For more information on these F/M pairs, refer to Documentation/badram.txt */
+
+static unsigned long __initdata badram_custom[] = {
+       0,      /* Number of longwords that follow, as F/M pairs */
+};
+
+
+/*********** CONFIG_BADRAM: CUSTOMISABLE SECTION ENDS HERE *******************/
+
+static int __init badram_setup (char *str)
+{
+       unsigned long opts[3];
+       BUG_ON(!mem_map);
+       printk (KERN_INFO "PAGE_OFFSET=0x%08lx\n", PAGE_OFFSET);
+       printk (KERN_INFO "BadRAM option is %s\n", str);
+       if (*str++ == '=')
+               while ((str = get_longoptions (str, 3, (long *) opts), *opts)) {
+                       printk (KERN_INFO "   --> marking 0x%08lx, 0x%08lx  [%ld]\n",
+                                       opts[1], opts[2], opts[0]);
+                       badram_markpages (*opts, opts+1);
+                       if (*opts == 1)
+                               break;
+               };
+       badram_markpages (*badram_custom, badram_custom+1);
+       return 0;
+}
+
+__setup("badram", badram_setup);
+
+#endif /* CONFIG_BADRAM */
+
+
+
+
 /* Return a pointer to the bitmap storing bits affecting a block of pages */
 static inline unsigned long *get_pageblock_bitmap(struct zone *zone,
 							unsigned long pfn)