From owner-freebsd-stable@FreeBSD.ORG Thu Oct 26 13:46:56 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 39B4316A407; Thu, 26 Oct 2006 13:46:56 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CAAF43D7E; Thu, 26 Oct 2006 13:46:33 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id k9QDkOXf033357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Oct 2006 15:46:26 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <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> <20061026143337.L29443@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02A6C9B5-1227-4D0A-AEF2-73B6187E1A08@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Thu, 26 Oct 2006 15:47:47 +0200 To: Robert Watson X-Mailer: Apple Mail (2.752.2) 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:46:56 -0000 Am 26.10.2006 um 15:37 schrieb Robert Watson: > 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. We had the machines running with ACPI disabled for a week or so, and we were still getting these panics, but I'll disable it again in the BIOS to make sure. > 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. So far, the machines always just hang instead of dumping core; I'll see if I can get them to write a dump. Can umastat be run against a live kernel? Then I could try running it as a cron job to record data up to just before the panic. Stefan -- Stefan Bethke Fon +49 170 346 0140