From owner-cvs-all  Wed Mar 14 21:10:11 2001
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id A3FA637B71A; Wed, 14 Mar 2001 21:10:07 -0800 (PST)
	(envelope-from peter@FreeBSD.org)
Received: (from peter@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f2F5A7c37697;
	Wed, 14 Mar 2001 21:10:07 -0800 (PST)
	(envelope-from peter)
Message-Id: <200103150510.f2F5A7c37697@freefall.freebsd.org>
From: Peter Wemm <peter@FreeBSD.org>
Date: Wed, 14 Mar 2001 21:10:07 -0800 (PST)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/i386/i386 locore.s mp_machdep.c pmap.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

peter       2001/03/14 21:10:07 PST

  Modified files:
    sys/i386/i386        locore.s mp_machdep.c pmap.c 
  Log:
  Kill the 4MB kernel limit dead.  [I hope :-)].
  For UP, we were using $tmp_stk as a stack from the data section.  If the
  kernel text section grew beyond ~3MB, the data section would be pushed
  beyond the temporary 4MB P==V mapping.  This would cause the trampoline
  up to high memory to fault.  The hack workaround I did was to use all of
  the page table pages that we already have while preparing the initial
  P==V mapping, instead of just the first one.
  For SMP, the AP bootstrap process suffered the same sort of problem and
  got the same treatment.
  
  MFC candidate - this breaks on 4.x just the same..
  
  Thanks to:	Richard Todd <rmtodd@ichotolot.servalan.com>
  
  Revision  Changes    Path
  1.143     +2 -2      src/sys/i386/i386/locore.s
  1.148     +10 -4     src/sys/i386/i386/mp_machdep.c
  1.277     +4 -3      src/sys/i386/i386/pmap.c


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message