More trapframe panics

[Stacey Son]

On Jan 28, 2014, at 4:09 AM, Joe Holden <lists at rewt.org.uk> wrote:

> On 27/01/2014 17:03, Adrian Chadd wrote:
>> Hi joe,
>> 
>> Can you post the backtrace? And resolve the symbol names for each of
>> the stackframes that show up?
>> 
>> It could be that there's some code doing dumb crap with stack frames
>> that we can fix in the source.
>> 
>> 
>> 
>> -a
>> 
> I'll try, wondering if this box also has ram problems as even though I regularly see page fault kernel messages on these, they don't usually lead to a userland crash.  Always helpful when fsck leaves the filesystem in a worse state than it started because it crashed :D
> 
> Will get debug kernel built and try and tickle it again, perl built fine in the end but libgcrypt upset it... is it worth applying those patches from CheriBSD?

Sorry, I'm little late to this thread.

The CheriBSD patch that Brooks posted links to increases the kernel thread stack size from 8K  to 16K (minus sizeof(struct pcb) ) at the expense of wiring another TLB entry.  In the case of CheriBSD the pcb is larger (see http://fxr.watson.org/fxr/source/mips/include/pcb.h?v=cheribsd;im=excerpts#L72).  This may be useful for other mips64 hardware, I don't know. The tradeoff, of course, is one less TLB entry and, therefore, more TLB pressure.  The larger term solution might be to increase the page size to 16K (by changing the PageMask) and use just one wired TLB entry for the kstack pages.  This will use a bit more memory for the kstacks (each kstack will be 32K), however.

The short answer is if you are using mips64 hardware and running out of kstack space then give the changes a try.

Best Regards,

-stacey.