From owner-freebsd-current@FreeBSD.ORG Fri Jun 24 21:31:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DAA516A41C for ; Fri, 24 Jun 2005 21:31:56 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1702743D49 for ; Fri, 24 Jun 2005 21:31:56 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-1.free.fr (Postfix) with ESMTP id 3B5851734AD for ; Fri, 24 Jun 2005 23:31:54 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.3/8.13.3) with ESMTP id j5OLVnj3004035; Fri, 24 Jun 2005 23:31:51 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Fri, 24 Jun 2005 23:31:45 +0200 User-Agent: KMail/1.8 References: <20050624145923.P83036@odysseus.silby.com> <200506242237.30270.thierry@herbelot.com> <20050624155218.D83036@odysseus.silby.com> In-Reply-To: <20050624155218.D83036@odysseus.silby.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200506242331.47205.thierry@herbelot.com> Cc: Mike Silbersack Subject: Re: new panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2005 21:31:56 -0000 Le Friday 24 June 2005 22:56, Mike Silbersack a écrit : > > That makes some sense, because we may not be getting around to the > modified memory until we hit some heavy memory usage. Also, one backtrace > showed the panic happening when uma_reclaim was called from the vm pageout > daemon. Sounds like I should throw something in to (optionally) call > uma_reclaim on a regular basis so that we might catch this more quickly. some light coming into the debate ! my test machine is somewhat low on memory (128Megs) and is used "headless", so the memory could only become rare somewhat late in the buildworld process. cheers, TfH