Date: Sat, 08 Dec 2012 21:32:19 +0100 From: Andre Oppermann <andre@freebsd.org> To: Oleksandr Tymoshenko <gonzo@bluezbox.com> Cc: svn-src-head@freebsd.org, alc@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, alfred@freebsd.org Subject: Re: svn commit: r243631 - in head/sys: kern sys Message-ID: <50C3A3D3.9000804@freebsd.org> In-Reply-To: <50C26AE9.4020600@bluezbox.com> References: <201211272119.qARLJxXV061083@svn.freebsd.org> <ABB3E29B-91F3-4C25-8FAB-869BBD7459E1@bluezbox.com> <50C1BC90.90106@freebsd.org> <50C25A27.4060007@bluezbox.com> <50C26331.6030504@freebsd.org> <50C26AE9.4020600@bluezbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <andre@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C3A3D3.9000804>