From owner-freebsd-current@FreeBSD.ORG Sat Jul 14 17:01:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A70BE106566B; Sat, 14 Jul 2012 17:01:16 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 700FF8FC08; Sat, 14 Jul 2012 17:01:16 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so8056766pbb.13 for ; Sat, 14 Jul 2012 10:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SZWV7xSUSiifW1jCUbelNQWaHyFCrr3m8GQXGWAQ0os=; b=L9Sh29SOFPfnWU/9H7JWAK6I3hr61QbzOspsPCBvioXnV06NI/qa+yQetbdNeNSuyr fnsiwiAB2BiZY90zDP/lkA2jkfu0YEwcTl06xNEHkdGmKl9nj0xKRMl40IVeQ5YFVYsB ITv5svFHDW6NtD/ZGsrC+5yXPP91zkP+xdnHua02x8WarWFUtHxapZ9mqgUiiBL01DqA Bmj7Gr06jIPB+3lbdKxJzxgWcJu/BDdkYE55/hWaf09hYY69kRUNMAVgNzvUDwGcC7JZ 42VcOEFF/CiGR4Xh4S8GWhhabnIlaiqKOOMI5tagpJRrI0JAlnPyCb0in7PcK2LHAQoQ zzcg== MIME-Version: 1.0 Received: by 10.66.81.106 with SMTP id z10mr10412805pax.26.1342285276001; Sat, 14 Jul 2012 10:01:16 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.208.168 with HTTP; Sat, 14 Jul 2012 10:01:15 -0700 (PDT) In-Reply-To: References: <307005B6-C8E5-4DCF-BD10-6BC79D8C2FE3@gmail.com> Date: Sat, 14 Jul 2012 10:01:15 -0700 X-Google-Sender-Auth: ZAI8j_cPZpXgG7iLt1plTml3Qxg Message-ID: From: mdf@FreeBSD.org To: Justin Hibbits Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current , FreeBSD PowerPC ML Subject: Re: panic with DEBUG_MEMGUARD on PowerPC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 17:01:16 -0000 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). I'll see about crafting a patch when I can get access to a machine that works (my current woes with my laptop, VM image, etc. are quite frustrating). The gist is that, in the absence of a kmem_max, the routine for determining the size of the kmem map should use the kernel_map's size as a limiting factor. In this case it looks like the map's size is 512MB. Cheers, matthew