From owner-freebsd-mips@FreeBSD.ORG Sun Jan 26 15:07:27 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEE04A2C for ; Sun, 26 Jan 2014 15:07:27 +0000 (UTC) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:140:72e1::ac16:e45e]) by mx1.freebsd.org (Postfix) with ESMTP id 60B641E75 for ; Sun, 26 Jan 2014 15:07:27 +0000 (UTC) Received: from hexe.rlwinm.de (p57A7C2FE.dip0.t-ipconnect.de [87.167.194.254]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id DC2E4FC2F for ; Sun, 26 Jan 2014 15:07:25 +0000 (UTC) Message-ID: <52E524BD.7090106@rlwinm.de> Date: Sun, 26 Jan 2014 16:07:41 +0100 From: Jan Bramkamp User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-mips@freebsd.org Subject: Re: More trapframe panics References: <52E42A1B.3040907@rewt.org.uk> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2014 15:07:28 -0000 On 25.01.2014 23:06, Juli Mallett wrote: > On Sat, Jan 25, 2014 at 1:18 PM, Joe Holden 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?