LinuxLists.cc - [PATCH 2.6.24] mm: BadRAM support for broken memory

[permalink] [raw]

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

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?

2008-03-02 17:42:54

[permalink] [raw]

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

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

2008-03-02 17:53:43

by Joseph Fannin

[permalink] [raw]

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

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
[email protected]

2008-03-02 19:34:34

[permalink] [raw]

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

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

2008-03-03 03:21:17

[permalink] [raw]

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

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

2008-03-03 05:46:40

by Nick Piggin

[permalink] [raw]

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

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

2008-03-03 07:14:55

[permalink] [raw]

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

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

2008-03-03 09:42:37

by Nick Piggin

[permalink] [raw]

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

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.

2008-03-03 09:49:09

[permalink] [raw]

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

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

2008-03-03 09:54:14

by Kamezawa Hiroyuki

[permalink] [raw]

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

On Mon, 3 Mar 2008 18:35:02 +1100
Nick Piggin <[email protected]> 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

2008-03-03 14:46:24

[permalink] [raw]

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

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

2008-03-03 16:41:23

[permalink] [raw]

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

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.

2008-03-03 17:43:42

by Randy Dunlap

[permalink] [raw]

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

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

2008-03-04 12:21:33

by Roland

[permalink] [raw]

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

>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

2008-03-04 13:27:50

by Ingo Molnar

[permalink] [raw]

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

* [email protected] <[email protected]> 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

2008-03-04 13:43:39

[permalink] [raw]

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

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

2008-03-04 14:01:01

by Roland

[permalink] [raw]

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

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

2008-03-04 14:07:00

by Ingo Molnar

[permalink] [raw]

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

* Rick van Rein <[email protected]> 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

2008-03-04 15:05:26

[permalink] [raw]

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

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

2008-03-04 16:31:12

[permalink] [raw]

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

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

2008-03-04 16:47:57

by Ingo Molnar

[permalink] [raw]

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

* H. Peter Anvin <[email protected]> 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

2008-03-08 10:35:44

[permalink] [raw]

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

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

2008-03-08 10:37:18

[permalink] [raw]

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

Ingo Molnar wrote:
> * [email protected] <[email protected]> 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

2008-03-08 10:40:45

[permalink] [raw]

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

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

2008-03-08 11:13:43

by Jiri Kosina

[permalink] [raw]

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

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

2008-03-10 10:13:17

[permalink] [raw]

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

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

2008-03-10 11:24:28

[permalink] [raw]

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

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

2008-03-10 11:52:18

[permalink] [raw]

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

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

2008-03-10 14:23:24

[permalink] [raw]

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

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

2008-03-10 17:32:24

[permalink] [raw]

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

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

memmap=0x18690000$64K

or

memmap=0x18690000$0x10000

-hpa

2008-03-10 17:48:34

[permalink] [raw]

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

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

2008-03-10 19:00:29

[permalink] [raw]

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

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 <[email protected]>

... 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, [email protected]
+
+
+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 <[email protected]>

Best regards,
Jan-Simon

2008-03-10 19:17:33

[permalink] [raw]

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

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

hmmm, change that to 2k8 !

2008-03-10 22:09:17

[permalink] [raw]

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

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

2008-03-10 22:55:51

[permalink] [raw]

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

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, [email protected]
> +
> +
> +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 <[email protected]>

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

2008-03-11 00:37:47

[permalink] [raw]

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

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 <[email protected]>

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, [email protected]
+
+
+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 <[email protected]>

2008-03-11 00:41:20

[permalink] [raw]

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

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

2008-03-11 06:51:50

[permalink] [raw]

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

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

2008-03-11 17:24:05

by Len Brown

[permalink] [raw]

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

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

2008-03-11 17:50:12

[permalink] [raw]

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

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 <[email protected]>

--- /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, [email protected]
+
+
+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 <[email protected]>

2008-03-11 19:26:53

by Johannes Weiner

[permalink] [raw]

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

Hi Jan-Simon,

Jan-Simon Möller <[email protected]> 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 <[email protected]>

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

2008-03-11 20:01:46