From owner-freebsd-current Wed Aug 5 09:04:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06952 for freebsd-current-outgoing; Wed, 5 Aug 1998 09:04:13 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles246.castles.com [208.214.165.246]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06943 for ; Wed, 5 Aug 1998 09:04:07 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id IAA03275; Wed, 5 Aug 1998 08:58:26 -0700 (PDT) Message-Id: <199808051558.IAA03275@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: meyerd1@fang.cs.sunyit.edu, phk@critter.freebsd.dk, current@FreeBSD.ORG Subject: Re: page faults and swapping In-reply-to: Your message of "Wed, 05 Aug 1998 18:17:15 +1000." <199808050817.SAA10585@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Aug 1998 08:58:26 -0700 From: Mike Smith 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. Fortunately, in -current with VM86 defined this isn't an issue, as we can query BIOS functions which are able to report the hole correctly. Another reason for VM86 to become the default. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message