From owner-freebsd-hackers  Sat Aug 23 09:49:52 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA01359
          for hackers-outgoing; Sat, 23 Aug 1997 09:49:52 -0700 (PDT)
Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA01352
          for <hackers@FreeBSD.ORG>; Sat, 23 Aug 1997 09:49:49 -0700 (PDT)
Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65])
	by pat.idi.ntnu.no (8.8.6/8.8.6) with ESMTP id SAA06260;
	Sat, 23 Aug 1997 18:49:39 +0200 (MET DST)
Message-Id: <199708231649.SAA06260@pat.idi.ntnu.no>
To: gordon@drogon.net
Cc: hackers@FreeBSD.ORG
Subject: Re: Problems with > 256MB of RAM [what worked & what didn't]
In-Reply-To: Your message of "Sat, 23 Aug 1997 14:46:46 +0100 (BST)"
References: <Pine.LNX.3.95.970823144610.10666D-100000@unicorn>
X-Mailer: Mew version 1.70 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sat, 23 Aug 1997 18:49:37 +0200
From: Tor Egge <Tor.Egge@idi.ntnu.no>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> Tor Egge <Tor.Egge@idi.ntnu.no> suggested:
> > There are two main reasons for this type of panic
> > 
> >         1. temporary shortage of free physical memory (cf PR#2431).
> >
> >            Use sysctl to increase limits of reserved free physical
> >            memory, reducing the probability for running out of free memory.
> > 
> >                 sysctl -w vm.v_free_reserved=1024
> >                 sysctl -w vm.v_free_min=1500
> 
> This worked.
> 
> Tor also suggested:
> >         2. permanent shortage of virtual memory allocated for pv entries.
> >
> >            Increase the size of allocated virtual memory for pv entries
> >            by adding:
> >                
> >                 options         "PMAP_SHPGPERPROC=400"
> 
> This didn't work. Upping it to 800 didn't work either. Same panic at the
> same place.

Both problems are capable of causing the panic by itself.
Applying a workaround for problem #2 and not for problem #1 when
problem #1 occurs will prevent the panic.

problem #1 normally occurs during fork of a process with a large
resident set (several hundred megabytes).

problem #2 normally occurs when you have many processes with the
same data mapped into memory (several hundred megabytes), and all the
processes have accessed most of that data.

If you have *very* many processes sharing the same data, the
workaround for problem #2 might cause problem #3, reported in PR#1880
(panic: kmem_suballoc: bad status return of 3).

> John S. Dyson <toor@dyson.iquest.net> suggested changing NKPDE in pmap.h
> (DG's patch bumped this from 63 to 127). I upped it to 255. Didn't work.
> Machine didn't even boot! Stopped at:
> 
>   Boot:
>   dosdev= 80, biosdrive = 0, unit = 0, maj = 0
>   Booting 0:wd(0,a)/kernel @ 0x100000
>   text=0x8f000 data=0xc000 bss=0xd484 symbols=[+0xb7c+0x4+0xc378+0x4+0x10169]
>   total=0x1c54e9 entry point=0x100000
> 
> Needed a hardware reset.

But that is trying to apply a workaround for problem #3, not problem #2
or problem #1, which are the two problems related to
`panic: get_pv_entry: cannot get a pv_entry_t'.

If you bump NKPDE to 255, you need to change LOAD_ADDRESS to C0100000
in sys/i386/conf/Makefile.i386. Did you do that ?

- Tor Egge