From owner-freebsd-commit  Wed Jul 19 00:12:39 1995
Return-Path: commit-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id AAA09652
          for commit-outgoing; Wed, 19 Jul 1995 00:12:39 -0700
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id AAA09637
          for cvs-sys-outgoing; Wed, 19 Jul 1995 00:12:35 -0700
Received: from Root.COM (implode.Root.COM [198.145.90.1])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id AAA09629
          ; Wed, 19 Jul 1995 00:12:26 -0700
Received: from corbin.Root.COM (corbin [198.145.90.18]) by Root.COM (8.6.11/8.6.5) with ESMTP id AAA18614; Wed, 19 Jul 1995 00:11:43 -0700
Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.11/8.6.5) with SMTP id AAA00404; Wed, 19 Jul 1995 00:13:01 -0700
Message-Id: <199507190713.AAA00404@corbin.Root.COM>
To: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
cc: CVS-commiters@freefall.cdrom.com, cvs-sys@freefall.cdrom.com
Subject: Re: cvs commit: src/sys/i386/include pmap.h 
In-reply-to: Your message of "Tue, 18 Jul 95 23:48:53 PDT."
             <199507190648.XAA06403@gndrsh.aac.dev.com> 
From: David Greenman <davidg@Root.COM>
Reply-To: davidg@Root.COM
Date: Wed, 19 Jul 1995 00:13:01 -0700
Sender: commit-owner@FreeBSD.org
Precedence: bulk

>> 
>> davidg      95/07/18 23:37:13
>> 
>>   Modified:    sys/i386/i386  machdep.c
>>                sys/i386/include  pmap.h
>>   Log:
>>   Rewrote memory sizing code to generally deal with holes in extended memory.
>>   This code change should allow certain Compaq machines with a 128K hole
>>   at 16MB to work.
>
>And probably just fixed a problem for all PS/2 ABIOS class machines
>with a simliar ``hole'', but often larger (15->16MB is missing on
>a true blue PS/2 ABIOS machine.)

   Unfortunately, it doesn't yet have a mechanism that allows you to say "I
have a memory hole in this range of addresses, so please skip it". The code
tries to figure it out by itself and this will obviously fail if there are
some shared memory devices that are addressed in the hole. I'm sure you agree
that it would be bad to add that shared memory into the global page pool. :-)
   I don't know how to deal with this problem. It almost needs to be a
userconfig'able sort of thing. Perhaps two configurable holes that can be
specified to map out a given area would be sufficient for most cases. Anyway,
my point is only that the mechanism doesn't yet exist.

-DG