Took a look at my DIMMs last night and noticed some interesting things:
1)  One DIMM was PC133 rated (shouldn't be an issue in my opinion since this 
system is 100 MHz FSB)
2)  The three other DIMMs had the same part number but one had a different PCB 
layout/shape.

I removed the PC133 DIMM and the odd shaped DIMM and installed the matched 
pair in slots 0 and 1.  I can now compile, etc without crashing.  I am still 
curious why memtest86 did not find a problem with the other dimms but am just 
happy to be able to compile a kernel etc.

Thanks for the suggestions.

>===== Original Message From gemorga2 <gemorga2@vt.edu> =====
>I thought ram could be the issue and tried running the memtest86 (version 
3.0)
>floppy.  It ran through 2 passes of the default set of tests without a single
>failure.  At any rate, I will try removing various ram modules and seeing if
>things work better.
>
>>===== Original Message From Manuel Bouyer <bouyer@antioche.eu.org> =====
>>On Fri, Nov 28, 2003 at 11:37:22PM -0500, gemorga2 wrote:
>>> Below is a boot from boot[1|2] floppy images captured via serial console
>(null
>>> modem cable to my laptop)
>>> Note the ps and trace output.  Let me know if you need more info:
>>>
>>> > boot
>>> booting fd0a:netbsd
>>> 3207712-
>>> Please remove disk 1, insert disk 2, and press return...
>>> +2144868+164800=0x5441b8
>>> [ netbsd ELF symbol table not valid ]
>>> [ netbsd a.out symbol table not valid ]
>>> [ no symbol table formats found ]
>>> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002
>>>     The NetBSD Foundation, Inc.  All rights reserved.
>>> Copyright (c) 1982, 1986, 1989, 1991, 1993
>>>     The Regents of the University of California.  All rights reserved.
>>>
>>> NetBSD 1.6.1 (INSTALL) #0: Tue Apr  8 12:46:48 UTC 2003
>>>
>>> scsibus0: waiting 2 seconds for devices to settle...
>>> sd0 at scsibus0 target 0 lun 0: <COMPAQ, DGHS09Y, 03F1> SCSI3 0/direct
>fixed
>>> sd0: 8678 MB, 8152 cyl, 10 head, 218 sec, 512 bytes/sect x 17773500 
sectors
>>> sd0: sync (50.0ns offset 15), 16-bit (40.000MB/s) transfers, tagged
>queueing
>>> sd1 at scsibus0 target 1 lun 0: <HP, 9.10GB A 80-SA40, SA40> SCSI2 
0/direct
>>> fixe
>>> d
>>> sd1: 8678 MB, 11474 cyl, 5 head, 309 sec, 512 bytes/sect x 17773524 
sectors
>>> sd1: sync (50.0ns offset 16), 16-bit (40.000MB/s) transfers, tagged
>queueing
>>> sd2 at scsibus0 target 2 lun 0: <COMPAQ, HB00931B93, A195> SCSI2 0/direct
>>> fixed
>>> sd2: 8678 MB, 5273 cyl, 20 head, 168 sec, 512 bytes/sect x 17773500 
sectors
>>> sd2: sync (50.0ns offset 16), 16-bit (40.000MB/s) transfers, tagged
>queueing
>>> scsibus1: waiting 2 seconds for devices to settle...
>>> md0: internal 2048 KB image area
>>> sd0: no disk label
>>> sd1: no disk label
>>> sd2: no disk label
>>> boot device: fd0
>>> root on md0a dumps on md0b
>>> root file system type: ffs
>>> warning: no /dev/console
>>> init: Creating mfs /dev
>>> NMI ... going to debugger
>>> Stopped in pid 2557 (chgrp) at  0xc02788d4:     repe movsl
>>
>>An NMI can be caused by a RAM parity error. Make sure you don't have a dead
>>RAM module.
>>
>>--
>>Manuel Bouyer <bouyer@antioche.eu.org>
>>     NetBSD: 24 ans d'experience feront toujours la difference
>>--
>
>George Morgan

George Morgan