Date: Tue, 7 Dec 2010 14:41:09 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: mdf@FreeBSD.org Cc: src-committers@FreeBSD.org, Alan Cox <alc@rice.edu>, alc@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, Max Khon <fjoe@samodelkin.net> Subject: Re: svn commit: r216016 - head/sys/sparc64/include Message-ID: <20101207134109.GI38282@alchemy.franken.de> In-Reply-To: <AANLkTinhyfHmdP4K5QVC5tv%2BGN%2BfzNpvU%2BV4JKF_cMHv@mail.gmail.com> References: <201011281926.oASJQKiE040689@svn.freebsd.org> <20101128194542.GF9966@alchemy.franken.de> <AANLkTinwkVO%2BRkr7coYGhuMdZ_UQQa3_18c3D6fBLucA@mail.gmail.com> <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> <AANLkTinhyfHmdP4K5QVC5tv%2BGN%2BfzNpvU%2BV4JKF_cMHv@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <marius@alchemy.franken.de> 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, 1994 > > ? ? ? ?The Regents of the University of California. All rights reserved. > > 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/usr/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. What are the actual > values of vm_kmem_size, kernel_map->min_offset, kernel_map->max_offset > at panic time? vm_kmem_size=5610405888 min_offset=3221225472 max_offset=13958643712 This is on a US3i machine with 16GB RAM. > How 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101207134109.GI38282>