From owner-freebsd-stable@FreeBSD.ORG Thu Oct 26 13:37:53 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B58A16A4A0 for ; Thu, 26 Oct 2006 13:37:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 722A643D9B for ; Thu, 26 Oct 2006 13:37:40 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D1F1D46E62; Thu, 26 Oct 2006 09:37:39 -0400 (EDT) Date: Thu, 26 Oct 2006 14:37:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stefan Bethke In-Reply-To: Message-ID: <20061026143337.L29443@fledge.watson.org> References: <20061025183308.L33725@fledge.watson.org> <838FCA83-20F8-4A09-A025-E69956032F86@lassitu.de> <45400286.9020402@samsco.org> <20061026091253.J69980@fledge.watson.org> <20061026111723.K33725@fledge.watson.org> <20152564-EC53-4210-9590-23817A6A3E42@lassitu.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Andreas Sons , FreeBSD Stable Subject: Re: panic: kmem_map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 13:37:53 -0000 On Thu, 26 Oct 2006, Stefan Bethke wrote: > acpica 3024 159K 20026966 ... > db> show uma > Zone Allocs Frees Used Cache > 64 9990754 9986054 4700 9980755 Looks like acpica has gone crazy performing allocation/freeing at a very high rate, and that for some reason, UMA is failing to properly reuse/release memory. So there are two bugs/problems here: whatever is causing ACPI to behave this way, and then the fact that UMA is failing to deal properly with its misbehavior. Alternatively, that we have a bug in the way statistics are handled. If you can generate a coredump, it would be quite useful to be able to run umstat (src/tools/tools/umastat in HEAD) on it. The tool probably needs a bit of tweaking to run on the core dump -- in particular, the first and second arguments of kvm_open() need to be the name of the kernel and dumpfile, rather than NULL. This would help confirm what actual state UMA is in. Robert N M Watson Computer Laboratory University of Cambridge