mm: BadRAM support for broken memory

+#define PG_badram 20 /* BadRam page */

in general,
Agreed with we need bad memory treatness.

Quoted 1 line

+#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?

Quoted 4 lines

Quoted 1 line

+#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.

Quoted 1 line

for show_mem() improvement?

For code clarity.

Hi

in general,
Agreed with we need bad memory treatness.

Quoted 1 line

+#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?

Quoted 3 lines

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 ;)

Quoted 6 lines

Quoted 3 lines

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?

Quoted 4 lines

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.

Quoted 9 lines · KOSAKI Motohiro

Quoted 6 lines

Quoted 3 lines

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?

Quoted 4 lines

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.

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

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

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

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.

Quoted 5 lines

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?

Hi!

Quoted 6 lines

Quoted 5 lines

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.

Quoted 1 line

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.

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.

Documentation/badram.txt +18 -0

+       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

Documentation/badram.txt +19 -0

+       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

Documentation/badram.txt +6 -0

+
+       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,

Documentation/badram.txt +14 -0

+       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

Documentation/kernel-parameters.txt +1 -0

+
 	baycom_epp=	[HW,AX25]
 			Format: <io>,<mode>
 

diff -pruN linux-2.6.24.orig/Documentation/memory.txt linux-2.6.24/Documentation/memory.txt

include/asm-x86/page_64.h +0 -0

 #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

mm/page_alloc.c +0 -0

@@ -4378,6 +4381,91 @@ EXPORT_SYMBOL(pfn_to_page);
 EXPORT_SYMBOL(page_to_pfn);
 #endif /* CONFIG_OUT_OF_LINE_PFN_TO_PAGE */
 

mm/page_alloc.c +10 -0

+               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));
+       }

Quoted 6 lines

Quoted 1 line

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.

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

How is this different from:

	memmap=<size>$<len>

Quoted 9 lines

Quoted 1 line

... ?

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".