three kernel patches for review

[Matthew Dillon]

:
:On Thu, 21 Apr 2005 07:56:18 +0200
:Raphael Marmier <raphael at xxxxxxxxxxx> wrote:
:
:> That's interesting, but how do you know the location of the bad 
:> addresses? Run memtest at boot?
:> Run memtest manually and export a table of bad addresses to a file?
:>
:> As we are pushing further in the product life, more and more bits are 
:> going to break. How do we handle that?
:
:1. Suspect bad RAM.
:2. Run e.g. memtest86 from its floppy.
:3. Note locations of bad bits, if any.
:4. Add those values to the vm.blacklist setting.
:5. Repeat until there are too many bad bits to justify keeping the
:   stick any more.
:
:It would be great to have something even more convenient, like a RAM
:test at boot time which automatically appends its findings to the
:vm.blacklist.  That would be correspondingly more work to implement, of
:course...
:
:-Chris
:
    memtest won't necessarily find the problem(s).  If a memory problem
    isn't due to a stuck bit (and most aren't), then it will depend on
    a billion factors that no memory testing program can ever test
    reliably.  The only solution to bad memory is usually to replace
    the stick or replace the computer.  Sometimes you can de-tune a
    computer (e.g. slow down the FSB, and a clock to the RAS and CAS
    cycles, etc) to fix marginal memory.

    Another poster noted that the BIOS might report memory where there
    is actually I/O.  This is a reasonable basis for putting in *some*
    sort of hack but I don't think that the VM page lists are the
    right place for that sort of thing.  

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>