The very current current  2.0F works fine with 768MB RAM (dual PIII@1260).
Faulty RAM perhaps?

Jaromir

Chris Ross wrote:
> 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
> 

-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
-=- We should be mindful of the potential goal, but as the Buddhist -=-
-=- masters say, ``You may notice during meditation that you        -=-
-=- sometimes levitate or glow.   Do not let this distract you.''   -=-