From owner-freebsd-current Wed Aug 5 01:17:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA08381 for freebsd-current-outgoing; Wed, 5 Aug 1998 01:17:39 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA08374 for ; Wed, 5 Aug 1998 01:17:35 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id SAA10585; Wed, 5 Aug 1998 18:17:15 +1000 Date: Wed, 5 Aug 1998 18:17:15 +1000 From: Bruce Evans Message-Id: <199808050817.SAA10585@godzilla.zeta.org.au> To: meyerd1@fang.cs.sunyit.edu, phk@critter.freebsd.dk Subject: Re: page faults and swapping Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The problem could be reproduced, but I was able to isolate a bad >simm and that took care of my problems. Unfortunately I had memory hole >enabled in the bios and this made it much more difficult to isolate the >problem. The kernel's memory probe would only pick up the first 16384K. >The MAXMEM option had to be enabled for anything more than 16384K. If there's any device memory in the hole, then you shouldn't be happy to let the probe look at any memory in the hole or above. The probe may be confused by device memory (it may think it is normal RAM), and the probe doesn't understand any holes except the ISA one at 640K-1M, so there is no way to probe memory above the hole without risking confusion. The BIOS may have protected against such problems by reporting the extended memory size as the amount below the hole. Setting MAXMEM may defeat this protection. Holes above 64MB would cause similar problems even if MAXMEM is not set. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message