Subject: Re: Please audit pool use in your code!
To: Thor Lancelot Simon <firstname.lastname@example.org>
From: David Brownlee <abs@NetBSD.org>
Date: 09/04/2006 21:45:14
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
David/absolute -- www.NetBSD.org: No hype required --