From owner-svn-src-all@FreeBSD.ORG Sat Dec 8 20:32:34 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8398B985 for ; Sat, 8 Dec 2012 20:32:34 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D78758FC16 for ; Sat, 8 Dec 2012 20:32:33 +0000 (UTC) Received: (qmail 60361 invoked from network); 8 Dec 2012 22:02:03 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Dec 2012 22:02:03 -0000 Message-ID: <50C3A3D3.9000804@freebsd.org> Date: Sat, 08 Dec 2012 21:32:19 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Oleksandr Tymoshenko 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> In-Reply-To: <50C26AE9.4020600@bluezbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, alc@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, alfred@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 20:32:34 -0000 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. Hopefully alc@ (added to cc) can answer that and also why the kmap of 27MB manages to wrench the ARM kernel. -- Andre