From owner-svn-src-all@FreeBSD.ORG Tue Dec 14 06:35:07 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A34501065672; Tue, 14 Dec 2010 06:35:07 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh6.mail.rice.edu (mh6.mail.rice.edu [128.42.201.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0A4958FC19; Tue, 14 Dec 2010 06:35:04 +0000 (UTC) Received: from mh6.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh6.mail.rice.edu (Postfix) with ESMTP id 4628F28F80B; Tue, 14 Dec 2010 00:35:04 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh6.mail.rice.edu, auth channel Received: from mh6.mail.rice.edu ([127.0.0.1]) by mh6.mail.rice.edu (mh6.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 9BW-udByKdeB; Tue, 14 Dec 2010 00:35:04 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh6.mail.rice.edu (Postfix) with ESMTPSA id 0E75C28F808; Tue, 14 Dec 2010 00:35:02 -0600 (CST) Message-ID: <4D071016.2040909@rice.edu> Date: Tue, 14 Dec 2010 00:35:02 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100725) MIME-Version: 1.0 To: Marius Strobl References: <201011281926.oASJQKiE040689@svn.freebsd.org> <20101128194542.GF9966@alchemy.franken.de> <20101129192308.GX80343@alchemy.franken.de> <20101129192417.GA18893@alchemy.franken.de> <4CF691A5.8070608@rice.edu> <20101202164727.GB38282@alchemy.franken.de> <4CF7D711.9040505@rice.edu> <20101206220733.GG38282@alchemy.franken.de> <20101207134109.GI38282@alchemy.franken.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mdf@FreeBSD.org, src-committers@freebsd.org, alc@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Max Khon Subject: Re: svn commit: r216016 - head/sys/sparc64/include X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 06:35:07 -0000 mdf@FreeBSD.org wrote: > On Tue, Dec 7, 2010 at 5:41 AM, Marius Strobl wrote: > >> On Mon, Dec 06, 2010 at 02:30:01PM -0800, mdf@FreeBSD.org wrote: >> >>> On Mon, Dec 6, 2010 at 2:07 PM, Marius Strobl wrote: >>> [lots of snip] >>> >>> >>>> With that one the kernel now survies memguard_init() but then panics >>>> right afterwards when kmeminit() calls kmem_suballoc(): >>>> KDB: debugger backends: ddb >>>> KDB: current backend: ddb >>>> Copyright (c) 1992-2010 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>>> ? ? ? ?The Regents of the University of California. All rights reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 9.0-CURRENT #18 r215249:216120M: Mon Dec ?6 13:27:57 CET 2010 >>>> ? ?marius@v20z.zeist.de:/home/marius/co/build/head2/sparc64.sparc64/usr/home/m4 >>>> WARNING: WITNESS option enabled, expect reduced performance. >>>> panic: kmem_suballoc: bad status return of 3 >>>> >>> [more snip] >>> >>> Shooting in the dark a little... >>> >>> The bad status of 3 is presumably KERN_NO_SPACE because we attempted >>> to allocate too much space from the kernel_map. What are the actual >>> values of vm_kmem_size, kernel_map->min_offset, kernel_map->max_offset >>> at panic time? >>> >> vm_kmem_size=5610405888 min_offset=3221225472 max_offset=13958643712 >> This is on a US3i machine with 16GB RAM. >> > > So kernel_map is from 0xC000_0000 to 0x3_4000_0000, or 0x2_8000_0000 > bytes large. Double the vm_kmem_size is 0x2_9CD0_0000, which is why > this is failing. > > This to me says that, for the moment, you need the > VM_MAX_KERNEL_ADDRESS define so that memguard does not take up too > much virtual space; at the moment this hardware is somewhat > constrained on virtual space. > Yes, I had thought that sparc64 had a much larger kernel address space. Marius, I would suggest that you revert back to Max's original commit that caps the kmem_map at 3/5 of the kernel address space. Right now, you are allowing the kmem_map to consume the entire kernel address space, and given the relatively modest size of the kernel address space, a machine with more physical memory may try to create a kmem_map that leaves no space for the buffer cache, pipes, thread stacks, etc. Alan