On Jun 12, 2004, at 04:38, Chris Ross wrote:
>   Now that that was ruled out, I tried the only other thing I
> could think to try.  I removed the upper 512MB of memory.  (I
> had 4 256MB DIMMs.  Now have only 2 256MB DIMMs.)  It will reliably
> install now, and doesn't seem to have any problem running.
>
>   However, I know this system was running just fine with BSD/OS
> on it, with all 1 GB of memory.  And, I know the BSD/OS kernel
> was configured to panic on parity-errors, so I wouldn't think
> that hardware-detected parity-errors are the problem.

   Okay.  It seems to run just fine with the 2 256MB DIMMs in it, but
if I put back either of the remaining ones, it will get an NMI (from
memcpy, called out of the uvm_ code).  Similar if I but them both
back.

   The trace I see right now (running with 1GB of memory) is:

memcpy(1f891000,20012000,0,6,c07cba80) at netbsd:memcpy+0x15:	repe 
movsl	(%esi),%es:(%edi)
uvm_fault(cbe5ee9c,bfbfd000,0,2,0) at netbsd:uvm_fault+0x523
trap() at netbsd:trap+0x38d
--- trap (number 6) ---
0x480e2710

   The x86 assembly I saw for the others looked the same.  Possibly
the same place in memcpy(), definately in those cases called from
uvm_something, but I don't think they too were uvm_fault().

   Does anyone have an x86 machine running GENERIC, with more
than 512 MB of memory?  I'd like to know if someone else could load
up the 20040517-2.0E snapshot, and have this *not* happen.

    I'm running the kernel I got in the binary sets, KERN-GENERIC.

                                   - Chris