From owner-freebsd-ppc@FreeBSD.ORG Fri Jul 13 01:11:17 2012 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 931221065670; Fri, 13 Jul 2012 01:11:17 +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 5F7968FC0A; Fri, 13 Jul 2012 01:11:17 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so5080280pbb.13 for ; Thu, 12 Jul 2012 18:11:17 -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=e8JG8PY3voB1BPcJfQzkYg2OSd12BZA7WLwSiDc3HO8=; b=avdTi0/e1IRP4v5YzdKovS+Mj9iUBgVtS+IcgUlkWvgjxTdQ3V3q9vFEe70PRh+7cm bznN8gG9Gtak9zkoALHc9SbIPGzweMILDoyU99qKxEDCyVAmoBqHakvuqqA1ia55MXeQ SdwUF1If7fnB/X/q1rDrtBTafQ9evr/2cchGdxkyeUoCaFXACI/QQnQHH2lfv4XyfF/o 2kt9/RoH1qyLJgzHyuKHoJYg3x8JiVUT0dDAUFUzQ3VAU/NnYeMLuBAP4/9ygJ+gj3hb T75QXq/MfkxkTCJvUa+eYzVobft0cMUx8uYRLXw/p6Bn3dxAJl+cu0/f6dNaAS7HqBqB l/CQ== MIME-Version: 1.0 Received: by 10.68.242.7 with SMTP id wm7mr9930544pbc.98.1342141877141; Thu, 12 Jul 2012 18:11:17 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.68.208.168 with HTTP; Thu, 12 Jul 2012 18:11:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 18:11:16 -0700 X-Google-Sender-Auth: _wikGF-DUsKYgcAYh54rkxtSq6c 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-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: Fri, 13 Jul 2012 01:11:17 -0000 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: > > panic: kmem_suballoc: bad status return of 3 > cpuid = 0 > KDB: stack backtrace: > 0xd0004ad0: at kdb_backtrace+0x4c > 0xd0004b40: at panic+0x224 > 0xd0004ba0: at kmem_suballoc+0x8c > 0xd0004bd0: at kmeminit+0x1ac > 0xd0004c20: at mi_startup+0x13c > 0xd0004c50: at btext+0xc0 > > 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. Thanks, matthew