[net.bugs.4bsd] Fix for 8 Mb memory limit

pwb@trwrba.UUCP (06/27/84)

1984-0074             TRW/UNIX Modification             1984-0074

NAME
     memory - only 8 megabytes of physical memory supported

DATE ENACTED
     June 22, 1984

KEYWORDS
     kernel, memory

PROBLEM DESCRIPTION
     The new MS780E memory controller will support a maximum of
     16 megabytes of physical memory but the kernel will only
     support at most 8 megabytes.

RESOLUTION
     The 8 megabyte restriction appears in two places.  First,
     the bit field sizes in the cmap structure are tuned to an 8
     megabyte maximum (exactly 13 bits).  Secondly, that portion
     of the assembly code support which discovers the total
     amount of available physical memory contains a hard coded 8
     megabyte limit.

     In cmap.h the bit fields c_next, c_prev and c_hlink must be
     increased in size from 13 to 14 bits and order of elements
     in the cmap structure must be rearranged to avoid crossing a
     word boundary in the middle of a field.  The new structure
     is:

     /*
      * core map entry
      */
     struct cmap
     {
     unsigned int  c_next:14,    /* index of next free list entry */
                   c_prev:14,    /* index of previous free list entry */
                   c_mdev:4,     /* which mounted dev this is from */
                   c_page:16,    /* virtual page number in segment */
                   c_hlink:14,   /* hash link for <blkno,mdev> */
                   c_type:2,     /* type CSYS or CTEXT or CSTACK or CDATA */
                   c_blkno:20,   /* disk block this is a copy of */
                   c_ndx:10,     /* index of owner proc or text */
                   c_lock:1,     /* locked for raw i/o or pagein */
                   c_want:1,     /* wanted */
                   c_intrans:1,  /* intransit bit */
                   c_free:1,     /* on the free list */
                   c_gone:1;     /* associated page has been released */
     };

     In locore.s change the code

         /* count up memory */

4.1bsd                    TRW (6/27/84)                         1

1984-0074             TRW/UNIX Modification             1984-0074

            clrl r7
         1: pushl $4; pushl r7; calls $2,_badaddr; tstl r0; bneq 9f
            acbl $8096*1024-1,$64*1024,r7,1b

     to

         /* count up memory */
            clrl r7
         1: pushl $4; pushl r7; calls $2,_badaddr; tstl r0; bneq 9f
            acbl $8096*1024*2-1,$64*1024,r7,1b
     allowing the kernel to count up to 16 megabytes of physical
     memory.

FILES
     /usr/src/sys/h/cmap.h         1.2
     /usr/include/sys/cmap.h       1.2
     /usr/src/sys/sys/locore.s     1.3

REQUESTOR
     Michael Gorlick

AUTHOR
     Michael Gorlick

REMARKS
     Similar changes must be made to go from 16 to 32 megabytes.
     However, for efficiency reasons, the constants of
     .../h/vmparam.h should also be resized.  Since a VAX 11/780
     or 785 doesn't have the raw speed to make good use of 32
     megabytes of memory it isn't worth the trouble now to
     accomodate the maximum memory configuration.

     Thanks to Lou Nelson, Aerospace who brought the problem to
     my attention and provided the definitive solution.

4.1bsd                    TRW (6/27/84)                         2

joe@fluke.UUCP (Joe Kelsey) (07/13/84)

There is a problem with the posted fix.  Simply modifying cmap.h and
changing the constant on the memory counting loop in the system startup
isn't quite enough.  The routine Fastreclaim at the end of locore.s has
various cmap constants wired into it:  namely the size of struct cmap
and the bit offsets of the fields c_intrans and c_free.  If you don't
fix these, you will start seeing random, seemingly arbitrary core dumps
on your system because the Fastreclaim loop is incorrectly marking text
pages as referenced or not.  Here is my fix:

/*	locore.s	6.3	83/08/12	*/
	.
	.
	.
/*
 * Extracted and unrolled most common case of pagein (hopefully):
 *	resident and not on free list (reclaim of page is purely
 *	for the purpose of simulating a reference bit)
 *
 * Built in constants:
 *	CLSIZE of 2, USRSTACK of 0x7ffff000, any bit fields
 *	in pte's or the core map
 */
	.text
	.globl	Fastreclaim
Fastreclaim:
	.
	.
	.
	subl2	_firstfree,r0
	ashl	$-1,r0,r0	
	incl	r0			# pgtocm(pte->pg_pfnum) 
#ifdef FLUKE
	/*
	 * changed size of cmap from 12 to 16 bytes to handle larger
	 * memories.
	 * 12-July-1984 jmk
	 */
	ashl	$4,r0,r0		# &cmap[pgtocm(pte->pg_pfnum)]
#else
	mull2	$12,r0
#endif FLUKE
	addl2	_cmap,r0		# &cmap[pgtocm(pte->pg_pfnum)] 
	tstl	r2
	jeql	2f			# if (type == CTEXT &&
#ifdef FLUKE
	/*
	 * rearranged fields within cmap for same reasons as above.
	 * 12-July-1984 jmk
	 */
/*	jbc	$0,12(r0),2f		#     c_intrans) */
	blbc	12(r0),2f		#     c_intrans)
#else
	jbc	$29,4(r0),2f		#     c_intrans)
#endif FLUKE
	POPR; rsb			# 	let pagein handle it
2:
#ifdef FLUKE
	/*
	 * ditto above
	 * 12-July-1984 jmk
	 */
	jbc	$1,12(r0),2f		# if (c_free)
#else
	jbc	$30,4(r0),2f		# if (c_free)
#endif FLUKE

It's nice that Fastreclaim is optimized, etc., but I wish there was
some way to symbolically refer to some of these constants.  Maybe I'll
add some #defines to cmap.h specifically for use in locore.s with some
comments in cmap.h and locore referring specifically to each other.
Note that I am assuming you are using the cmap.h structure posted by
Philib Bonesteele @ TRW.  norman@cithep also sent me a modified cmap.h
which has the fields rearranged differently.  Anyway, we've been
running on the above mods overnight and no random core dumps yet.  The
problem has always shown up very quickly in the past, so I feel
confident that I finally have the problem solved.  Now I can finally
use all 10 M bytes of memory!  Goodbye swapper!!!

/Joe