Date: Sat, 16 Oct 2004 13:27:24 +0200 From: Willem Jan Withagen <wjw@withagen.nl> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA7 install cd: kernel trap 12 with interrupts disabled Message-ID: <4171059C.9070908@withagen.nl> In-Reply-To: <20041015220203.GT83620@cirb503493.alcatel.com.au> References: <20041013214911.GD986@green.homeunix.org> <Pine.NEB.3.96L.1041014045808.84384U-100000@fledge.watson.org> <20041015073118.GA19660@gvr.gvr.org> <20041015104856.GB45863@cirb503493.alcatel.com.au> <20041015123547.GA23221@gvr.gvr.org> <20041015220203.GT83620@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4171059C.9070908>