Date: Sun, 26 Jan 2014 16:07:41 +0100 From: Jan Bramkamp <crest@rlwinm.de> To: freebsd-mips@freebsd.org Subject: Re: More trapframe panics Message-ID: <52E524BD.7090106@rlwinm.de> In-Reply-To: <CACVs6=--Qy_8poWdHdCXYKqkO22=dvHhW8=Uma8kLR%2BhCoZDxw@mail.gmail.com> References: <52E42A1B.3040907@rewt.org.uk> <CACVs6=--Qy_8poWdHdCXYKqkO22=dvHhW8=Uma8kLR%2BhCoZDxw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25.01.2014 23:06, Juli Mallett wrote: > On Sat, Jan 25, 2014 at 1:18 PM, Joe Holden <lists@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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52E524BD.7090106>