Subject: Re: NMI on Compaq 1850R (was Re: cac problems with 2.0E-20040517)
To: None <current-users@NetBSD.org>
From: Chris Ross <email@example.com>
Date: 06/13/2004 18:28:40
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
The trace I see right now (running with 1GB of memory) is:
memcpy(1f891000,20012000,0,6,c07cba80) at netbsd:memcpy+0x15: repe
uvm_fault(cbe5ee9c,bfbfd000,0,2,0) at netbsd:uvm_fault+0x523
trap() at netbsd:trap+0x38d
--- trap (number 6) ---
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.