From owner-freebsd-mips@freebsd.org Tue Mar 6 23:19:35 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A987EF38D9F for ; Tue, 6 Mar 2018 23:19:35 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from saturn.lyxys.ka.sub.org (saturn.lyxys.ka.sub.org [217.29.35.151]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2695770E67; Tue, 6 Mar 2018 23:19:34 +0000 (UTC) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (juno.lyx [IPv6:fd2a:89ca:7d54:0:240:caff:fe92:4f47]) by saturn.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id w26NJAHZ033427 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL); Wed, 7 Mar 2018 00:19:12 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) Received: from juno.lyxys.ka.sub.org (localhost [127.0.0.1]) by juno.lyxys.ka.sub.org (8.15.2/8.15.2) with ESMTPS id w26NJAFJ079301 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Mar 2018 00:19:10 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) Received: (from wolfgang@localhost) by juno.lyxys.ka.sub.org (8.15.2/8.15.2/Submit) id w26NJAdW079300; Wed, 7 Mar 2018 00:19:10 +0100 (CET) (envelope-from wolfgang@lyxys.ka.sub.org) X-Authentication-Warning: juno.lyx: wolfgang set sender to wolfgang@lyxys.ka.sub.org using -f Date: Wed, 7 Mar 2018 00:19:10 +0100 From: Wolfgang Zenker To: Juli Mallett Cc: John Baldwin , freebsd-mips@freebsd.org Subject: Re: ELF - panic on installworld Message-ID: <20180306231910.GA79006@lyxys.ka.sub.org> References: <20180305211635.GA21623@lyxys.ka.sub.org> <5A9DEE9E.6050906@grosbein.net> <5A9DF0D6.7090306@grosbein.net> <1949943.3JoNfSzP6x@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: private site User-Agent: Mutt/1.9.4 (2018-02-28) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (saturn.lyxys.ka.sub.org [IPv6:fd2a:89ca:7d54:1:200:24ff:feca:b4cc]); Wed, 07 Mar 2018 00:19:13 +0100 (CET) X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 23:19:35 -0000 * Juli Mallett [180306 21:14]: > On 6 March 2018 at 10:29, John Baldwin wrote: >> On Tuesday, March 06, 2018 08:37:26 AM Eugene Grosbein wrote: >>> 06.03.2018 8:27, Eugene Grosbein wrote: >>>> 06.03.2018 4:16, Wolfgang Zenker wrote: >>>>> I'm trying to run installworld using 11-STABLE on an Ubiquity Edge >>>>> Router Lite (mips64, 2 cores, 512 MB Ram). Unfortunately I haven't >>>>> managed to finish the installworld yet, I always get a >>>>> panic: kernel stack overflow - trapframe at 0xffffffff80917eb0 >>>>> in slightly different places during the installworld. Of the 4 panics >>>>> I have seen on the serial console, 3 had the trapframe at >>>>> 0xffffffff80917eb0 and one at 0xffffffff80915eb0 >>>>> /usr/src and /usr/obj are nfs-mounted, and I have configured almost 2 GB >>>>> of swap. The build was done in a Qemu environment. >>>>> Any hints how to proceed from here? >>>> Try increasing kernel stack size from default 2 pages to 4 by rebuilding >>>> the kernel with options KSTACK_PAGES=4 >>> Note also, that depending on your network configuration, KSTACK_PAGES=4 >>> may or may not be enough. If it does not help, you need to double it >>> once more. >> KSTACK_PAGES doesn't work on MIPS because the MIPS kstack has to be >> hardwired >> into the TLB and the code that does that assumes a hardcoded stack size. > That said, we could easily use a more flexible wired TLB entry scheme, > including smartly using pagemask in the cases where the number of pages is > suitable. If we wanted to allow wiring of mappings into the TLB flexibly > at runtime we could do that, or we could just at compile-time have > different code to handle different KSTACK_PAGES values. People have strong > feelings about some of those options, but if there's a workload-oriented > pressure to move in a different direction, it should be very easy to do. I would welcome a more flexible solution, of course. However, I guess my situation is a bit unusual: the ERL is an unusually powerful machine for a mips based network device, and therefore I want to experiment with it trying different options without dismantling the device for every update to switch in a new usb stick. I think most users just set it up once and only update in case of security problems. Anyhow, if a more flexible solution could be done without to much effort, please do it. If I can help by testing, please let me know.