Re: 5.3-BETA7 install cd: kernel trap 12 with interrupts disabled

Robert Watson wrote:

>On Fri, 15 Oct 2004, Guido van Rooij wrote:
>
>  
>
>>It turns out this was a memory problem. Refitting the dimms was all
>>that was needed to 'solve' the issue. The weird thing is that
>>1. The BIOS had memtesting enabled and did not complain
>>2. W2K seemed to install ok (though I never let it hit the disk)
>>3. FBSD would repeatedly crash at exactly the same spot.
>>
>>I am beginning to wonder if we should have a boot option that enables a
>>thorough memtest from within the kernel...(e.g. boot -m). 
>>    
>>
>
>I guess the old /dev/test_for_shoddy_workmanship driver is working :-).
>
>It's probably just bad luck -- BIOS memory testing is generally pretty
>poor, and it could just be FreeBSD stored your root vnode pointer (or some
>other critical thing) in a memory word that Win2K was using for an icon,
>so a single bit twiddle did pretty different things.  Glad it's fixed.  I
>occasionally wonder if we shouldn't build a memory tester into the FreeBSD
>boot loader to help diagnose this sort of stuff, though.  Not to run every
>boot, but as a diagnostics option.
>  
>
BIOS memory testing is just a test to see if the memory is there. The 
memory is not really  seriously excersised.

I would like to offer my help for doing that... Like I wrote Guido 
already in private: The first time I raised that question was when FBSD 
was still at 2.0.x. And I do have some experience in memory testing, 
since long time ago, I designed a hardware statemachine which tested 
embedded memory for large memories on big VLSI designs. But there used 
to be enough material on memory testing out there. Problem is that there 
are a lot of memory tests, and some of the memories errors only show if 
certain sequences of 1 and 0's are applied to the bit under test as well 
as to the neighboring memory cells. And for that you'd need to know the 
internal layout/architecture of the chips one is using.

The way I was thinking, can this be a kld which is load and executed at 
the boot prompt. Or be "added" on the boot prompt, but then executed 
before anything else. Have the memory look like one large and flat 
address space would make programming very simple for most tests.
I would also make it somewhat interactive since one would like to be 
able to set the degree of testing. Otherwise testing 2Gb might take a 
few weeks, if the only mode was to apply all tests.
Other thing that will be in our way is that caching. During memory 
testing caches need to be disabled. Now this is always processor 
specific a presume?? But then caches need to be tested as well (unless 
they are tested the embedded way :) ), which is a totally different cookie.

--WjW