From owner-svn-src-head@FreeBSD.ORG Fri Dec 7 21:05:47 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 040B0B0A; Fri, 7 Dec 2012 21:05:47 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 9074C8FC13; Fri, 7 Dec 2012 21:05:46 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Th579-0001vC-Lu; Fri, 07 Dec 2012 13:05:45 -0800 Message-ID: <50C25A27.4060007@bluezbox.com> Date: Fri, 07 Dec 2012 13:05:43 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 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> In-Reply-To: <50C1BC90.90106@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: 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. > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, alfred@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: Fri, 07 Dec 2012 21:05:47 -0000 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 Alfred, should these lines be defined for all 32-bit architectures?