ELF - panic on installworld

[Wolfgang Zenker]

* Juli Mallett <juli at northcloak.com> [180306 21:14]:
> On 6 March 2018 at 10:29, John Baldwin <jhb at 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.

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.