On Mon, 4 Sep 2006, Thor Lancelot Simon wrote:

> On Mon, Sep 04, 2006 at 05:16:21PM +0100, David Brownlee wrote:
>> 	Further to this. I've only seen this on amd64 boxes running
>> 	i386 (as opposed to i386 boxes running i386, which is my
>> 	only relevant reference).
>>
>> 	In one case about ten days ago I took the disks, memory
>> 	and display card from one box which was seeing the
>> 	uvm_fault(..., 0, 0, 1) -> 0xe issue and put them into a
>> 	32bit Athlon box and not seen the issue since.
>>
>> 	A tentative hypothesis would be that it could be amd64 specific,
>> 	or 'sk' nic specific.
>
> It's not 'sk' nic specific; we have bge nics.

 	All my amd64 systems ended up with sk's and non of my i386 boxes
 	have any - it was the other obvious difference my end, but good
 	to have it excluded.

> But the machines in question do, in fact, run 32 bit kernels on amd64
> hardware.  Is there any chance you could try running the original system
> in 64-bit mode?

 	That may be somewhat nontrivial - I don't have anything
 	running am64 currently. I presume dropping a NetBSD-4.0_BETA
 	amd64 kernel into an i386 userland and packages would not
 	be a recipe for happiness...

 	I'll try and see if I can get it tested, but it may take me
 	a while to get it setup, as the only machines on which I've
 	seen ths issue are 'live'.

 	The other other thing the amd64 boxes may be doing which
 	the i386 are not is interleaving memory, and on at least
 	one of them I had to turn that off based on memtester
 	reporting occasional errors with it enabled. Of course for
 	some of the production boxes I've been pigheaded enough to
 	get ECC memory for them (which disables interleaving on
 	the asus A8V-Deluxe motherboard), but unfortunately not
 	all.

-- 
 		David/absolute       -- www.NetBSD.org: No hype required --