From owner-freebsd-hackers Thu Apr 6 11: 2: 9 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id 1372A37BF56 for ; Thu, 6 Apr 2000 11:01:58 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97]) by probity.mcc.ac.uk with esmtp (Exim 1.92 #3) id 12dGbM-000Pcn-00; Thu, 6 Apr 2000 19:01:56 +0100 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.9.3/8.9.3) id TAA30830; Thu, 6 Apr 2000 19:01:56 +0100 (BST) (envelope-from jcm) Date: Thu, 6 Apr 2000 19:01:56 +0100 From: J McKitrick To: Brooks Davis Cc: hackers@FreeBSD.ORG Subject: Re: bad memory patch? Message-ID: <20000406190156.B30755@dogma.freebsd-uk.eu.org> References: <20000406164114.B29984@dogma.freebsd-uk.eu.org> <20000406101325.C10876@orion.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000406101325.C10876@orion.ac.hmc.edu>; from brooks@one-eyed-alien.net on Thu, Apr 06, 2000 at 10:13:25AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 06, 2000 at 10:13:25AM -0700, Brooks Davis wrote: > On Thu, Apr 06, 2000 at 04:41:15PM +0100, J McKitrick wrote: > > I saw this link recently... > > > > http://home.zonnet.nl/vanrein/badram/ > > > > Apparently, you make a floppy with the supplied image, boot with it to > > find the bad RAM addresses, and then those addresses are passed on as a > > kernel parameter once the patch is applied. Bad addresses will be excluded > > from addressable/virtual memory from then on. > > > > Sounds like sometheing we could use, eh? > > Not really. If you run it and it says the RAM is bad you know it's bad. > If you run it and it says the RAM is good, then you whine and batch and > moan for weeks, if not months, that FreeBSD is busted and your machine > is perfectly functional until you finaly replace the RAM and the problem > goes away. This is not what we want to see. The problem is that > testing can't prove correctness because it can't try EVERY possiable > access combination. 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. > P.S. The "you" in the above doens't refer to the poster, it refers to > the poor sucker with a problem who tries to use this so called tool. jm -- ------------------------------------------------------------------- Jonathon McKitrick -- jcm@freebsd-uk.eu.org To Microsoft: "Your tyranny I was part of, is now cracking on every side. Now your own life is in danger. Your Empire is on fire." Front 242 ------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message