More trapframe panics

[Jan Bramkamp]

On 25.01.2014 23:06, 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.
> 
> Now, you do correctly say that stack overflows were made less frequent,
> presumably by reducing stack usage by things that were using too much, and
> while that may be the case now, it seems less and less likely, and more
> likely that reasonable stack usage is leading to problems.
> 
> I hope at least some of that is useful or at least gives more insight into
> what's going on.  I don't want you to feel ignored, and I don't want to
> give the false expectation that a fix is around the corner.  It would be
> very easy for someone to change the code so that we just use 4 pages of
> kernel stack rather than 2, but it doesn't seem like that's a pressing
> matter for anyone who has the time to work on it, unfortunately.
> 
> WITNESS won't add anything, and may actually make your problem worse, as
> there will likely be deeper stacks on average with WITNESS or other
> debugging options compiled in.  You're doing everything right, but
> unfortunately FreeBSD is just a little deficient right now.  We're all
> lucky that it's uncommon enough that people can use 64-bit MIPS at all,
> although maybe we're unlucky in the sense that it didn't present as a
> pressing issue when much of the 64-bit work was first being done.
> 
> Thanks,
> Juli.

Would increasing KSTACK_PAGES from two to three or four help? What are
the trade-offs involved in choosing KSTACK_PAGES for something like the
EdgeMax Lite?