Date: Tue, 6 Mar 2018 12:14:27 -0800 From: Juli Mallett <juli@northcloak.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-mips@freebsd.org Subject: Re: ELF - panic on installworld Message-ID: <CAGSiXYw3m3sPJJb0_Vyr=XWEd4vdu9sypPieqXbqSJJkJ2K6BA@mail.gmail.com> In-Reply-To: <1949943.3JoNfSzP6x@ralph.baldwin.cx> References: <20180305211635.GA21623@lyxys.ka.sub.org> <5A9DEE9E.6050906@grosbein.net> <5A9DF0D6.7090306@grosbein.net> <1949943.3JoNfSzP6x@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6 March 2018 at 10:29, John Baldwin <jhb@freebsd.org> 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. Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGSiXYw3m3sPJJb0_Vyr=XWEd4vdu9sypPieqXbqSJJkJ2K6BA>