More trapframe panics

[Brooks Davis]

On Sat, Jan 25, 2014 at 02:06:51PM -0800, Juli Mallett wrote:
> On Sat, Jan 25, 2014 at 1:18 PM, Joe Holden <lists at rewt.org.uk> wrote:
> 
> > Hi,
> >
> 
> 
> > Just chucked 10.0-R onto an ERL here, already hit a trapframe panic when
> > building several ports, IIRC these were fixed before?
> >
> 
> First off, there's no such thing as a "trapframe panic" first off ??? a
> trapframe is a structure which contains all of the registers that are saved
> when a trap occurs.  Every panic can be associated with a trapframe, but in
> most cases the trapframe is available through the thread or some other
> indirection.  In this case, because the stack has overflowed, things are in
> a bad state, and the kernel gives you the address of the trapframe because
> it might be difficult to find otherwise under the circumstances.
> 
> panic: kernel stack overflow - trapframe at 0xffffffff80753eb0
> >
> 
> As the panic message says here, you're seeing a kernel stack overflow.
>  This is not a single class of problem; kernel stack overflows are caused
> by there being more data on the stack than the kernel stack can contain.
>  This happens easily on 64-bit MIPS because due to slightly-crummy design
> on our part there's proportionally less room on the stack than on a 32-bit
> system.  Several people have nebulous plans to address the problem of the
> stack being too small, but I don't know of anyone intending concrete action
> going forward.
> 
> You may want to report these as exactly what the meaningful part of the
> panic says, a "kernel stack overflow", as you'll be more likely to get the
> right kind of help/attention for the problem, although given that we know
> the kernel stack is simply too small, there may not be much to be gained by
> reporting it.  Adrian will say that reporting it is good because it reminds
> developers that there's a problem, but I don't think anyone working on
> 64-bit MIPS isn't aware that this is a problem at this point.  This isn't a
> single bug which needs to be fixed, but a structural problem and a known
> one, and so I worry it's likely to be frustrating for you if you're putting
> effort in to reporting these, since resolution is probably going to be
> elusive, or at least indirect.

Stacey has implemented a change to double the kernel stack size to 16K
by adding a another wired TLB entry.  It is sufficient to let us use NFS
on CHERI (which has much bigger context due to another 32 256-bit
registers).  The changes are in the CheriBSD github:

https://github.com/CTSRD-CHERI/cheribsd/commit/8db80374b098414b0435352eef54b5afefe18d90
https://github.com/CTSRD-CHERI/cheribsd/commit/a9ae6dc7bb65457fe4732c19c71e8d30541643fe
https://github.com/CTSRD-CHERI/cheribsd/commit/efd25472a36b9aed6910e630661a4a296a88f5f8

I think we're leaning toward switching the stack to larger pages as the
longer term solution to avoid wasting TLB entries.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-mips/attachments/20140127/86094136/attachment.sig>