Skip site navigation (1)Skip section navigation (2)
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>