Date: Sat, 08 Dec 2012 15:21:54 -0600 From: Alan Cox <alc@rice.edu> To: Andre Oppermann <andre@freebsd.org> Cc: src-committers@freebsd.org, alc@freebsd.org, svn-src-all@freebsd.org, alfred@freebsd.org, Oleksandr Tymoshenko <gonzo@bluezbox.com>, svn-src-head@freebsd.org Subject: Re: svn commit: r243631 - in head/sys: kern sys Message-ID: <50C3AF72.4010902@rice.edu> In-Reply-To: <50C3A3D3.9000804@freebsd.org> 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> <50C3A3D3.9000804@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C3AF72.4010902>