Date: Sat, 06 Sep 1997 04:54:11 +0200 From: Tor Egge <tegge@idi.ntnu.no> To: ian@gamespot.com Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: get_pv_entry panic Message-ID: <199709060254.EAA20637@pat.idi.ntnu.no> In-Reply-To: Your message of "Fri, 05 Sep 1997 12:12:15 -0700" References: <3.0.3.32.19970905121215.0126ba80@mail.gamespot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Any idea what > > /kernel: panic: get_pv_entry: cannot get a pv_entry_t > means? Depending on the value of nppvapg, the machine was out of free physical memory (problem #1, PR#2431, npvvapg>0) or address space in the kernel reserved for pv_entries (problem #2, npvvapg==0). For problem #1, the workaround is to increase vm.v_free_reserved and vm.v_free_min through use of sysctl. I use 1024 and 1500 here, but with 128 MB memory, 256 and 375 should normally be sufficient. For problem #2, the workaround is to increase maxusers or define PMAP_SHPGPERPROC to a higher value than the default by an entry in the kernel config file. > Running 2.2-970618-RELENG on 128 megs of ram, a bunch of SCSI disks, this > machine performs log analysis on very large logs, if that helps. There's > mention on freebsd-questions recently of adding > options "PMAP_SHPGPERPROC=400" > to the kernel but that that might make the kernel panic at boot time due to > running out of VM space. What's the deal? The old pmap code (before PMAP_SHPGPERPROC was introduced) reserved 224 MB of address space for pv_entries when 512 MB memory was available. This caused the problem reported in PR#1880. With the new pmap code, that problem will probably only occur if a more than 112 MB address space is reserved for pv_entries, i.e. when the product of PMAP_SHPGPERPROC and maxusers is more than 250000. - Tor Egge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709060254.EAA20637>