From owner-svn-src-head@FreeBSD.ORG Tue Nov 30 16:51:26 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52C751065673; Tue, 30 Nov 2010 16:51:26 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id DAF2E8FC1F; Tue, 30 Nov 2010 16:51:25 +0000 (UTC) Received: by qyk8 with SMTP id 8so1381288qyk.13 for ; Tue, 30 Nov 2010 08:51:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.184.143 with SMTP id ck15mr6343285qcb.181.1291135884510; Tue, 30 Nov 2010 08:51:24 -0800 (PST) Received: by 10.229.246.133 with HTTP; Tue, 30 Nov 2010 08:51:24 -0800 (PST) X-Originating-IP: [109.174.58.22] In-Reply-To: <20101129192417.GA18893@alchemy.franken.de> References: <201011281926.oASJQKiE040689@svn.freebsd.org> <20101128194542.GF9966@alchemy.franken.de> <20101129192308.GX80343@alchemy.franken.de> <20101129192417.GA18893@alchemy.franken.de> Date: Tue, 30 Nov 2010 22:51:24 +0600 Message-ID: From: Max Khon To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: svn-src-head@freebsd.org, alc@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r216016 - head/sys/sparc64/include X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 16:51:26 -0000 Marius, On Tue, Nov 30, 2010 at 1:24 AM, Marius Strobl wrote: > > > On Sun, Nov 28, 2010 at 07:26:20PM +0000, Max Khon wrote: > > > > > Author: fjoe > > > > > Date: Sun Nov 28 19:26:20 2010 > > > > > New Revision: 216016 > > > > > URL: http://svn.freebsd.org/changeset/base/216016 > > > > > > > > > > Log: > > > > > Define VM_KMEM_SIZE_MAX on sparc64. Otherwise kernel built with > > > > > DEBUG_MEMGUARD panics early in kmeminit() with the message > > > > > "kmem_suballoc: bad status return of 1" because of zero "size" > argument > > > > > passed to kmem_suballoc() due to "vm_kmem_size_max" being zero. > > > > > > > > > > The problem also exists on ia64. > > > > > > > > > > Modified: > > > > > head/sys/sparc64/include/vmparam.h > > > > > > > > > > Modified: head/sys/sparc64/include/vmparam.h > > > > > > > > > > ============================================================================== > > > > > --- head/sys/sparc64/include/vmparam.h Sun Nov 28 18:59:52 > 2010 > > > > (r216015) > > > > > +++ head/sys/sparc64/include/vmparam.h Sun Nov 28 19:26:20 > 2010 > > > > (r216016) > > > > > @@ -237,6 +237,14 @@ > > > > > #endif > > > > > > > > > > /* > > > > > + * Ceiling on amount of kmem_map kva space. > > > > > + */ > > > > > +#ifndef VM_KMEM_SIZE_MAX > > > > > +#define VM_KMEM_SIZE_MAX ((VM_MAX_KERNEL_ADDRESS - \ > > > > > + VM_MIN_KERNEL_ADDRESS + 1) * 3 / 5) > > > > > +#endif > > > > > + > > > > > +/* > > > > > * Initial pagein size of beginning of executable file. > > > > > */ > > > > > #ifndef VM_INITIAL_PAGEIN > > > > > > > > How was that value determined? > > > > > > > > > > I've just copied it from amd64 to be non-zero for now. Do you have a > better > > > idea of what it should look like? > > > > Well, on sparc64 VM_MAX_KERNEL_ADDRESS already is dynamically adjusted > > to the maximum appropriate for the specific CPU during the early cycles > > of the kernel so I'd think one could just use VM_MAX_KERNEL_ADDRESS - > > VM_MIN_KERNEL_ADDRESS for VM_KMEM_SIZE_MAX there, I'm not sure what > > the intention of the ceiling provided by that macro actually is though > Ok, this sounds reasonable. I changed it to be just (VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS) > In any case, the commit message of r180210 which changed the amd64 > > version to the current one talks about limiting the kmem map to 3.6GB > > and while it also fails to explain where that value comes from it > > looks rather amd64 specific and the formula used by the macro will > > result in a different ceiling on sparc64 and thus inappropriate. I've > > CC'ed alc@ who hopefully can shed some light on this. > > Apart from this the actual bug here seems to be that memguard_fudge() > > can't deal with a km_max being zero or that zero is passed to it as > > kmeminit() allows for VM_KMEM_SIZE_MAX not being defined. > I thought about fixing memguard_fudge() too, but defining VM_KMEM_SIZE_MAX seemed to be less intrusive change to me. Max