Date: Thu, 6 Apr 2000 11:19:19 -0700 From: Brooks Davis <brooks@one-eyed-alien.net> To: J McKitrick <jcm@freebsd-uk.eu.org> Cc: hackers@FreeBSD.ORG Subject: Re: bad memory patch? Message-ID: <20000406111919.A22381@orion.ac.hmc.edu> In-Reply-To: <20000406190156.B30755@dogma.freebsd-uk.eu.org>; from jcm@freebsd-uk.eu.org on Thu, Apr 06, 2000 at 07:01:56PM %2B0100 References: <20000406164114.B29984@dogma.freebsd-uk.eu.org> <20000406101325.C10876@orion.ac.hmc.edu> <20000406190156.B30755@dogma.freebsd-uk.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 06, 2000 at 07:01:56PM +0100, J McKitrick wrote: > I think the concept here is that it allows you to use the bad RAM. It's > like bad blocks on a hard drive. SO now, if you think you have bad RAM, you > can run the test, mark the bad blocks, and memory will be allocated 'around' > them. That would be fine if it were possiable to write a test which found all bad RAM, but you can't do that. I don't think this is the sort of thing we want anywhere near the project. It's just not possiable to make this sort of thing reliable. It's rather poor solution to the problem. The right solution is to buy RAM from a vendor with lifetime free replacement. It might cost a bit more, but you don't have to deal with unreliable hacks like this. It all comes back to the problem that if you test a complex system, you can prove it's bad but you can't prove it's good. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000406111919.A22381>