From owner-svn-src-head@FreeBSD.ORG Sat Dec 8 21:22:03 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10D3B1C7; Sat, 8 Dec 2012 21:22:03 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id C97388FC13; Sat, 8 Dec 2012 21:22:02 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 36051603DB; Sat, 8 Dec 2012 15:21:56 -0600 (CST) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id 3415E603D3; Sat, 8 Dec 2012 15:21:56 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id sxWOxMpaYUw1; Sat, 8 Dec 2012 15:21:56 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id 85DF4603B0; Sat, 8 Dec 2012 15:21:55 -0600 (CST) Message-ID: <50C3AF72.4010902@rice.edu> Date: Sat, 08 Dec 2012 15:21:54 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: svn commit: r243631 - in head/sys: kern sys References: <201211272119.qARLJxXV061083@svn.freebsd.org> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com> <50C3A3D3.9000804@freebsd.org> In-Reply-To: <50C3A3D3.9000804@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, alc@freebsd.org, svn-src-all@freebsd.org, alfred@freebsd.org, Oleksandr Tymoshenko , svn-src-head@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 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: Sat, 08 Dec 2012 21:22:03 -0000 On 12/08/2012 14:32, Andre Oppermann wrote: > On 07.12.2012 23:17, Oleksandr Tymoshenko wrote: >> On 12/7/2012 1:44 PM, Andre Oppermann wrote: >>> On 07.12.2012 22:05, Oleksandr Tymoshenko wrote: >>>> On 12/7/2012 1:53 AM, Andre Oppermann wrote: >>>>> On 07.12.2012 10:36, Oleksandr Tymoshenko wrote: >>>>>> >>>>>> On 2012-11-27, at 1:19 PM, Andre Oppermann >>>>>> wrote: >>>>>> >>>>>>> Author: andre >>>>>>> Date: Tue Nov 27 21:19:58 2012 >>>>>>> New Revision: 243631 >>>>>>> URL: http://svnweb.freebsd.org/changeset/base/243631 >>>>>>> >>>> .. skipped .. >>>>>> Andre, >>>>>> >>>>>> these changes along with r243631 break booting ARM kernels on >>>>>> devices with 1Gb of memory: >>>>>> >>>>>> vm_thread_new: kstack allocation failed >>>>>> panic: kproc_create() failed with 12 >>>>>> KDB: enter: panic >>>>>> >>>>>> If I manually set amount of memory to 512Mb it boots fine. >>>>>> If you need help debugging this issue or testing possible fixes, >>>>>> I'll be glad to help >>>>> >>>>> What is the kmem layout/setup of ARM? If it is like i386 then maybe >>>>> the parameters VM_MAX_KERNEL_ADDRESS and VM_MIN_KERNEL_ADDRESS are >>>>> not >>>>> correctly set up and the available kmem is assumed to be larger than >>>>> it really is. >>>>> >>>> >>>> VM_MIN_KERNEL_ADDRESS == 0xc0000000 >>>> VM_MAX_KERNEL_ADDRESS == 0xffffffff >>>> >>>> The problem goes away if I copy VM_MAX_AUTOTUNE_MAXUSERS and >>>> VM_MAX_AUTOTUNE_NMBCLUSTERS lines from i386/include/vmparam.h >>> >>> VM_MAX_AUTOTUNE_NMBCLUSTERS is unused now and can be garbage collected. >>> It was only ever defined in i386/include/vmparam.h. >>> >>> The calculation for maxusers is physpages / (2 * 1024 * 1024 / >>> PAGE_SIZE) >>> resulting in 512. >> >> Yes, it's 512 and then it's scaled down to 400. If maxusers is >> overridden by >> VM_MAX_AUTOTUNE_MAXUSERS (384), boot proceeds but then userland >> application fail >> with the same diagnostic: >> vm_thread_new: kstack allocation failed > > The trouble seems to come from NSFBUFS which is (512 + maxusers * 16) > resulting in a kernel map of (512 + 400 * 16) * PAGE_SIZE = 27MB. This > seem to be pushing it with the smaller ARM kmap layout. > > Does it boot and run when you set the tunable kern.ipc.nsfbufs=3500? > > ARM does have a direct map mode as well which doesn't require the > allocation > of sfbufs. I'm not sure which other problems that approach has. > Only a few (3?) platforms use it. It reduces the size of the user address space, and translation between physical addresses and direct map addresses is not computationally trivial as it is on other architectures, e.g., amd64, ia64. However, it does try to use large page mappings. > Hopefully alc@ (added to cc) can answer that and also why the kmap of > 27MB > manages to wrench the ARM kernel. > Arm does not define caps on either the buffer map size (param.h) or the kmem map size (vmparam.h). It would probably make sense to copy these definitions from i386. Alan