From owner-freebsd-stable@FreeBSD.ORG Thu Oct 26 00:34:23 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 B466C16A403; Thu, 26 Oct 2006 00:34:23 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6E9B43D5A; Thu, 26 Oct 2006 00:34:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9Q0YF4j093862; Wed, 25 Oct 2006 18:34:21 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <45400286.9020402@samsco.org> Date: Wed, 25 Oct 2006 18:34:14 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Stefan Bethke References: <20061025183308.L33725@fledge.watson.org> <838FCA83-20F8-4A09-A025-E69956032F86@lassitu.de> In-Reply-To: <838FCA83-20F8-4A09-A025-E69956032F86@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Andreas Sons , Robert Watson , 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 00:34:23 -0000 Stefan Bethke wrote: > > Am 25.10.2006 um 19:36 schrieb Robert Watson: > >> >> On Wed, 25 Oct 2006, Stefan Bethke wrote: >> >>> We're consistely getting this panic even under smallish loads. I've >>> experimented with various values for VM_KMEM_SIZE_MAX (384, 512, 768 >>> and 1024 MB), but the boxes are still panicking after even short >>> periods (a few hours) just doing a buildworld, a few ports compiles, >>> or even when logging out of the console(?). >>> >>> Would logging vm.zone every few minutes help detecting a kernel >>> memory leak? >>> >>> I'm at a complete loss as to the actual cause of these. The ACPI >>> errors precede the panic below by only a few seconds, so I'd guess >>> they're a symptom, not a cause. We've tried with ACPI disabled in >>> the BIOS, but we also got these panics, so we re-enabled it. >>> >>> The hardware is a Tyan GT20 (2865) with a single-core Opteron, two >>> gigs of RAM and two or three SATA disks. >>> >>> Any ideas? >> >> Try the commands "show uma" and "show malloc" in DDB to print the >> memory allocations made by the uma(9) and malloc(9) kernel memory >> allocators. This output may be sufficient to suggest to us where a >> kernel memory leak, if any, might be taking place. Also, a stack >> trace ("trace") never hurts; if something is sitting there allocating >> a lot of memory at high speed, it could well be that the last call to >> the memory allocator is the one leaking. > > Thanks, see below. I'll let it sit in the debugger, if someone has some > more ideas for what to look at. > > This panic was triggered by me trying to ssh into the box; it had been > sitting idle since the last reboot around 1900 CEST. Note that I had to > break into the debugger manually. I'm assuming that the memory shortage > is so severe that dumping cannot be initiated, so the kernel hangs... > > Thanks, > Stefan > There are no obvious culprits from what you posted. The kernel was only trying to allocate 60 bytes, and the 64-byte bucket didn't look to be overly used. None of the other zones look terribly over-used either. The 'show malloc' command doesn't really give enough stats to be terribly useful, IMHO. And neither of the commands can effectively track things like contig memory allocator. Can you try the following two commands: vmstat -m sysctl hw.busdma Also, what version of FreeBSD is this? Scott