From owner-freebsd-ppc@FreeBSD.ORG Sat Jul 14 15:39:47 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 25A05106564A; Sat, 14 Jul 2012 15:39:47 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8E88FC0C; Sat, 14 Jul 2012 15:39:46 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3091789qcs.13 for ; Sat, 14 Jul 2012 08:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; bh=lcbXdD4DIrAOIke/qnHbgDZfJaDQEKaQzS+bbd12xRM=; b=XrZOVWPwdXewN7KiXtoZnlHNYdMnKTXcrD673T97rKl9fm7ljUwIcp26Nr3GWk5t8M LE4TOXdgZFf7CF+vCXbf+0VikupPC66rtwx0T0BmdLGaCvpf5VKyZV71CuKxdewE0oi0 GeDU6TMRbtMXtWuN1aCZzp/Z4cntYOMs+VdZK0IIq64eWVTRKZiXuD3/6id/Gtq2ZIhE 8npT1sY27vw4RVfpQJph4pZG7+G80XuM7KKxogE0AlyVCzU7zq86ACtQQZA7/Qj4Frve Ixw39geGtWOFdTS9t+UAbiEgMXRlCVfUAkLgUUyu2fwM2LbZMlFsxGv3QkOthXcEa2Gl 35gA== Received: by 10.224.59.212 with SMTP id m20mr10514523qah.35.1342280386107; Sat, 14 Jul 2012 08:39:46 -0700 (PDT) Received: from triad.knownspace (pool-71-163-84-156.washdc.fios.verizon.net. [71.163.84.156]) by mx.google.com with ESMTPS id fx5sm15288208qab.14.2012.07.14.08.39.44 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 08:39:45 -0700 (PDT) Message-Id: From: Justin Hibbits To: mdf@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 14 Jul 2012 11:39:43 -0400 References: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> X-Mailer: Apple Mail (2.936) 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: Sat, 14 Jul 2012 15:39:47 -0000 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). - Justin