From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 11:27:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47DA316A4CE for ; Sat, 16 Oct 2004 11:27:31 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E07C43D1F for ; Sat, 16 Oct 2004 11:27:29 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with ESMTP id i9GBRN9S084432; Sat, 16 Oct 2004 13:27:24 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <4171059C.9070908@withagen.nl> Date: Sat, 16 Oct 2004 13:27:24 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20041013214911.GD986@green.homeunix.org> <20041015073118.GA19660@gvr.gvr.org> <20041015104856.GB45863@cirb503493.alcatel.com.au> <20041015123547.GA23221@gvr.gvr.org> <20041015220203.GT83620@cirb503493.alcatel.com.au> In-Reply-To: <20041015220203.GT83620@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA7 install cd: kernel trap 12 with interrupts disabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 11:27:31 -0000 Peter Jeremy wrote: >On Fri, 2004-Oct-15 14:35:47 +0200, Guido van Rooij wrote: > > >>A make buildworld cannot be used in sich a scenario. A nice memtester >>that could be called from the bootloader would have been handy. >> >> > >http://www.memtest86.com/memtest86-3.1a.iso.gz > >I'm not sure how much effort would be involved in making memtest[86] >in a form that could be loaded by the bootloader. > > > I'd be willing to do the work, but somebody needs to hold my hand in finding a place and way to get it early enough in the kernel. The memtest algorithms in themselves are not all that complex to program. The most complex ones just run in exponential time based on the size of the memory area to test. :( Which is way you'd prefer to know the memory architecture, so that you can segment the whole of the memory into smaller bits to test, and hence run faster. I need to dig in my paper archives, but I would still have the lecture materials on this. Another valid remark was made about the environment. temperature and power are also very influential factors for holding electrons in memory cells. And these are hard/impossible to influence whilest running the tests. An also important item for memory failure is refresh timing. It could be that the memory as such is correct, but that too much leakage causes bits to fall too fast. To detect this it requires that whole rows of the memory are not touched by either read or write for the duration of the refresh period. All in all again not very simple without knowing the memory architecture. These arguments have for me always been the reason, not to try implement a memory tester. Especially since most people using this will not be aware of limitted relevance of the tests they are running. But like I said, give me some pointers on how to plug it into the kernel, and I'll get going on this. --WjW