From owner-freebsd-bugs Thu Jan 9 05:50:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA29884 for bugs-outgoing; Thu, 9 Jan 1997 05:50:04 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id FAA29878; Thu, 9 Jan 1997 05:50:02 -0800 (PST) Resent-Date: Thu, 9 Jan 1997 05:50:02 -0800 (PST) Resent-Message-Id: <199701091350.FAA29878@freefall.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org, Tor.Egge@idt.ntnu.no Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA29774 for ; Thu, 9 Jan 1997 05:47:23 -0800 (PST) Received: from ikke.idt.unit.no (tegge@ikke.idt.unit.no [129.241.111.65]) by pat.idt.unit.no (8.8.4/8.8.4) with ESMTP id OAA08621 for ; Thu, 9 Jan 1997 14:47:18 +0100 (MET) Received: (from tegge@localhost) by ikke.idt.unit.no (8.8.4/8.8.3) id OAA01381; Thu, 9 Jan 1997 14:47:17 +0100 (MET) Message-Id: <199701091347.OAA01381@ikke.idt.unit.no> Date: Thu, 9 Jan 1997 14:47:17 +0100 (MET) From: Tor Egge Reply-To: Tor.Egge@idt.ntnu.no To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: i386/2431: panic: get_pv_entry: cannot get a pv_entry_t Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Number: 2431 >Category: i386 >Synopsis: panic: get_pv_entry: cannot get a pv_entry_t >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 9 05:50:01 PST 1997 >Last-Modified: >Originator: Tor Egge >Organization: Norwegian University of Science and Technology, Trondheim, Norway >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD ikke.idt.unit.no 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Fri Jan 3 16:55:28 MET 1997 root@ikke.idt.unit.no:/usr/src/sys-UP/compile/TEGGE i386 512 MB memory >Description: When a process with a lot of resident memory (>300 MB, where 180 MB is mlocked) forks while the amount of free physical memory is low, the system may run out of free memory when allocating elements of type pv_entry_t. When attempting to dump the memory to the dump device, the system tries to allocate even more elements of type pv_entry_t, causing a recursive panic, and no dump. >How-To-Repeat: See above. >Fix: Workaround: Use sysctl to increase limits of reserved free physical memory, reducing the probability for running out of free memory. e.g. sysctl -w vm.v_free_reserved=1024 sysctl -w vm.v_free_min=1500 >Audit-Trail: >Unformatted: