From owner-svn-src-head@FreeBSD.ORG Tue Dec 7 19:33:22 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 A16D91065672; Tue, 7 Dec 2010 19:33:22 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx1.freebsd.org (Postfix) with ESMTP id 37D4C8FC0C; Tue, 7 Dec 2010 19:33:21 +0000 (UTC) Received: by iwn40 with SMTP id 40so254137iwn.17 for ; Tue, 07 Dec 2010 11:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Z+6vkuDXyyqHaAe7lt/S9d1Oy9uPvTj2ESzvAS8IAbc=; b=elYsjK/gZ+gSg+sl7g5D1cFGUuc2qsJJDYodcYmZdRZNY2WrwTjHsb2pEYxKCsivHr MLp8B3FB42YtPJg6VMjydwORem7zif9j5h/0oCpU+/8tOOX9Yd2kfH6LJVPINQ1tnWQa 375xJRoJT+L/97Qyf7t9CwArkAq9PWePQ54lA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=L2QpRb5j1jaP/Gid8fd9zUNK7v8xtX8XYChM9AeXWtkohE0h7h7sB+tHSJ2sgXxs2m DZqPsSEPQvDhDvjpFDKtE2DOwrNKpDCzv2x56EeZcXa8qsCz0yHff+AvLJzvhs4sciWG bK+z8KqmOrnVTKP21jbSGNe0k5WL0j6juis3Y= MIME-Version: 1.0 Received: by 10.231.15.5 with SMTP id i5mr4286813iba.26.1291750401247; Tue, 07 Dec 2010 11:33:21 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.231.35.130 with HTTP; Tue, 7 Dec 2010 11:33:21 -0800 (PST) In-Reply-To: <20101207134109.GI38282@alchemy.franken.de> References: <201011281926.oASJQKiE040689@svn.freebsd.org> <20101128194542.GF9966@alchemy.franken.de> <20101129192308.GX80343@alchemy.franken.de> <20101129192417.GA18893@alchemy.franken.de> <4CF691A5.8070608@rice.edu> <20101202164727.GB38282@alchemy.franken.de> <4CF7D711.9040505@rice.edu> <20101206220733.GG38282@alchemy.franken.de> <20101207134109.GI38282@alchemy.franken.de> Date: Tue, 7 Dec 2010 11:33:21 -0800 X-Google-Sender-Auth: JRY3zSHWriVsfJ3X7jUDhOumLWU Message-ID: From: mdf@FreeBSD.org To: Marius Strobl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: src-committers@freebsd.org, Alan Cox , alc@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, Max Khon 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, 07 Dec 2010 19:33:22 -0000 On Tue, Dec 7, 2010 at 5:41 AM, Marius Strobl w= rote: > On Mon, Dec 06, 2010 at 02:30:01PM -0800, mdf@FreeBSD.org wrote: >> On Mon, Dec 6, 2010 at 2:07 PM, Marius Strobl wrote: >> [lots of snip] >> >> > With that one the kernel now survies memguard_init() but then panics >> > right afterwards when kmeminit() calls kmem_suballoc(): >> > KDB: debugger backends: ddb >> > KDB: current backend: ddb >> > Copyright (c) 1992-2010 The FreeBSD Project. >> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94 >> > ? ? ? ?The Regents of the University of California. All rights reserve= d. >> > FreeBSD is a registered trademark of The FreeBSD Foundation. >> > FreeBSD 9.0-CURRENT #18 r215249:216120M: Mon Dec ?6 13:27:57 CET 2010 >> > ? ?marius@v20z.zeist.de:/home/marius/co/build/head2/sparc64.sparc64/us= r/home/m4 >> > WARNING: WITNESS option enabled, expect reduced performance. >> > panic: kmem_suballoc: bad status return of 3 >> >> [more snip] >> >> Shooting in the dark a little... >> >> The bad status of 3 is presumably KERN_NO_SPACE because we attempted >> to allocate too much space from the kernel_map. =A0What are the actual >> values of vm_kmem_size, kernel_map->min_offset, kernel_map->max_offset >> at panic time? > > vm_kmem_size=3D5610405888 min_offset=3D3221225472 max_offset=3D1395864371= 2 > This is on a US3i machine with 16GB RAM. So kernel_map is from 0xC000_0000 to 0x3_4000_0000, or 0x2_8000_0000 bytes large. Double the vm_kmem_size is 0x2_9CD0_0000, which is why this is failing. This to me says that, for the moment, you need the VM_MAX_KERNEL_ADDRESS define so that memguard does not take up too much virtual space; at the moment this hardware is somewhat constrained on virtual space. Thanks, matthew > >> =A0How much virtual space does sparc64 support (since >> earlier it was reported it's computed based on hardware capability, >> for this specific machine?) >> > > Currently, the limiting factor is that the kernel TSB is addressed > virtually, which means that the TTEs for kernel TSB itself have to be > put into locked dTLB slots taking up 1 4MB dTLB slot per 1GB. US3 > family CPUs have 16 lockable 4MB dTLB and iTLB slots, which need to > be shared between the TSB and the kernel itself though, i.e. a 9MB > kernel also takes up 3 slots (US1/2 machines have 64 dTLB and iTLB > slots but there these are also used for unlocked TTEs so we don't use > more than 32 for kernel plus TSB on these). VM_MAX_KERNEL_ADDRESS is > limited according to how many slots are available for the TSB, that's > what I was referring to previously. > Actually, US3 and later as well as SPARC64 V and later CPUs have > a feature allowing the TSB to be addressed physically, circumventing > the need to lock the TSB into the TLB, thus allowing the full 64-bit > virtual address space to be used. Implementing that is on my TODO > list but unfortunately that's not exactly straight forward and also > requires some instructions to be patched at runtime so the kernel > still works on US1/2 machines. > > Marius > >