Date: Sat, 25 Jan 2014 14:06:51 -0800 From: Juli Mallett <jmallett@FreeBSD.org> To: Joe Holden <lists@rewt.org.uk> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: More trapframe panics Message-ID: <CACVs6=--Qy_8poWdHdCXYKqkO22=dvHhW8=Uma8kLR%2BhCoZDxw@mail.gmail.com> In-Reply-To: <52E42A1B.3040907@rewt.org.uk> References: <52E42A1B.3040907@rewt.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 =E2=80=94= 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. > cpuid =3D 0 > Uptime: 16h59m55s > > Don't have debugging on as the CPU is already slow enough :) > > Can boot a witness/whatever enabled kernel though if required... > > Thanks, > Joe > _______________________________________________ > freebsd-mips@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=--Qy_8poWdHdCXYKqkO22=dvHhW8=Uma8kLR%2BhCoZDxw>