Skip site navigation (1)Skip section navigation (2)
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>