From owner-freebsd-ppc@FreeBSD.ORG Sun Jul 15 20:18:25 2012 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6CCD4106566C; Sun, 15 Jul 2012 20:18:25 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id EB6598FC0C; Sun, 15 Jul 2012 20:18:24 +0000 (UTC) Received: by qaat11 with SMTP id t11so1212535qaa.13 for ; Sun, 15 Jul 2012 13:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=I/XC63zu0HtdwiRJL6UnhzK/79ZRYVbD+n1WfP2kF9g=; b=K/qjUL36Neulj2aLu69lMGPL1RozcHBIvnIXWyg3KBI5yoRE5ikt0tyrBjZ8L2BRUz Yhql0SZHMbphgwx0IPcyU7EDeSEFs9QKGhl8bwpUXWCHDvjeKUWnrSK68tExg7s9NGwI 7nDGKNLt2JhdCbMs+TPGEvmZ1edyC/vONvTHBRbCH6i9Vz4aHVUk4foz6yfSSYZj5uyj jqwZLNOZGnXv7iHaEpkPKg0Q3YV54xqdu9PWdBi4zBCfaWzYuhnhfmiI6ZJARhJcTM/k /b9G27Yr1Zb6t2hayIjRzkBBDwMIgLL2nAXvd4ZK6UE7+KDRRJmm6kg+4AtO/ftRaOBE tRig== Received: by 10.224.98.74 with SMTP id p10mr17184823qan.8.1342383504263; Sun, 15 Jul 2012 13:18:24 -0700 (PDT) Received: from narn.knownspace (pool-71-163-84-156.washdc.fios.verizon.net. [71.163.84.156]) by mx.google.com with ESMTPS id z9sm19977077qae.15.2012.07.15.13.18.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jul 2012 13:18:24 -0700 (PDT) Date: Sun, 15 Jul 2012 16:18:21 -0400 From: Justin Hibbits To: mdf@FreeBSD.org Message-ID: <20120715161821.7fbfff75@narn.knownspace> In-Reply-To: References: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; powerpc-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current , FreeBSD PowerPC ML Subject: Re: panic with DEBUG_MEMGUARD on PowerPC X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 20:18:25 -0000 On Sun, 15 Jul 2012 09:39:03 -0700 mdf@FreeBSD.org wrote: > On Sat, Jul 14, 2012 at 8:39 AM, Justin Hibbits > wrote: > > On Jul 13, 2012, at 12:20 AM, mdf@freebsd.org wrote: > > > >> On Thu, Jul 12, 2012 at 6:33 PM, Justin Hibbits > >> wrote: > >>> > >>> On Jul 12, 2012, at 9:11 PM, mdf@freebsd.org wrote: > >>> > >>>> On Thu, Jul 12, 2012 at 4:43 PM, Justin Hibbits > >>>> wrote: > >>>>> > >>>>> > >>>>> When tracking down a panic exposed by INVARIANTS, I tried > >>>>> setting DEBUG_MEMGUARD, so I could find the culprit that's > >>>>> trashing freed memory. > >>>>> However, this causes a panic at bootup. It shows up right > >>>>> after the first > >>>>> WARNING: WITNESS message, with the following: > >>>>> > >>>>> Tracing, and printf() debugging, I see arguments to > >>>>> vm_map_findspace(): start: 0xD0000000, length: 4246446080, and > >>>>> map->max_offset = 4026531839. > >>>>> > >>>>> Beyond that, I'm lost with tracking this down. Machine is a > >>>>> dual processor > >>>>> PowerPC G4, with 2GB RAM. > >>>> > >>>> > >>>> > >>>> The length is 0xFD1BA000 which is almost 4GB. Asking for 4GB of > >>>> virtual space for 2GB of RAM sounds about right (it's been a > >>>> while since I was in this code), unless this is a 32-bit kernel, > >>>> in which case it'd be too much since there isn't that much > >>>> virtual space available. > >>>> > >>>> So, is the kernel 32-bit? What are the values used and returned > >>>> by memguard_fudge()? The intent of that routine is to get > >>>> kmeminit() to allocate a larger map so memguard can use part of > >>>> it for private virtual addresses. But it shouldn't be asking > >>>> for "too much"; i.e. the intent was to check both physical and > >>>> virtual space available and be greedy, but not too greedy. > >>>> > >>>> There were some issues with that code for some platforms that > >>>> e.g. didn't define a VM_KMEM_SIZE_MAX, but alc@ fixed that in > >>>> r216425. > >>> > >>> > >>> It is a 32-bit kernel, on 32-bit hardware. The values for > >>> memguard_fudge are (defaults): > >>> > >>> tmp: 4246446080, vm_kmem_size: 117440512, vm_kmem_size_max: 0 > >>> > >>> When setting vm.kmem_size/vm.kmem_size_max to 2GB they are: > >>> > >>> tmp: 2147483648, vm_kmem_size: 214793648, vm_kmem_sizee_max: > >>> 2147483648 (all > >>> 2GB). > >>> > >>> But the start and map->max_offset remain the same on all runs I > >>> make. > >> > >> > >> memguard_fudge is still broken for 32-bit architectures with no > >> vm_kmem_max. In the absence of a km_max to limit the value, we > >> essentially use twice the physical memory for the virtual limit. > >> But with 2GB on a 32-bit machine, this requires 4GB of virtual > >> space. > >> > >> Setting vm_kmem_size_max to 2GB should work; I'd expect to see > >> tmp=about 200MB, which is much larger than the input 112MB but the > >> allocation should work. But I don't really know what else PowerPC > >> has need of for virtual space, so that still could be too large. > >> > >> You can try smaller values of vm_kmem_size_max, like 1GB or 512MB. > >> You shouldn't need to set vm_kmem_size at all. At some point the > >> added space for the memguard_map will be small enough that the > >> kmem_suballoc will work. > >> > >> Hmm, what is the min_offset and max_offset of kernel_map when the > >> call to memguard_fudge is made? > >> > >> Thanks, > >> matthew > > > > > > > > Without setting vm.kmem_size/vm.kmem_size_max, I see the following: > > > > map: 0x1000000, min_offset: 0xD0000000, max_offset: 0xEFFFFFFF > > > > It does boot when I set vm.kmem_size=256M/vm.kmem_size_max=512M. > > > > When I tried 512M/1024M, it panicked at the same place -- > > kmem_suballoc from kmeminit. So it looks like I have to set > > vm.kmem_size/vm.kmem_size_max way back in order for it to boot with > > memguard(9). > > Please try the attached patch (or at > http://people.freebsd.org/~mdf/memguard.diff). > > Thanks, > matthew Hi Matthew, That patched works perfectly. Thanks, Justin