From owner-freebsd-mips@FreeBSD.ORG Sat Jan 25 22:07:20 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 A85BADC6 for ; Sat, 25 Jan 2014 22:07:20 +0000 (UTC) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A33F1B49 for ; Sat, 25 Jan 2014 22:07:19 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id ec20so3586391lab.9 for ; Sat, 25 Jan 2014 14:07:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=WYf0feGlzlySGBbY3IOBfn2x68zI0T1K6xg2+3ty7Ik=; b=kAgz3w9+nBU9yeGijYE59qJcONL/ebMxQrEZotX0R7dpXZhzig3A1d6y3M18H4LsfH wxwJqNLvDbBqxI7gzySbmuEjTJumafJNWSENocgGwCl7jMf7obAJWwiYRSZPXmBaplhc 0rmuxle4x3ZEkrSQuOYWRYcpYJ8Y8CojGP8FhvuJBdnme1BgYy8HXwaOle3JsTQwH16A 3zMPu6EOPpvyhZZVUVjtgXDtAyh7OmI7ZteEiAERBP+S5pSDrcIcroNzmT01F1qBN+Sg t3dKhtMSBagDn254mTvU2HefuDxdI/iLikqAch3hGVznBB6LIH9roIKaBW5issMYsiUQ 8WSA== X-Gm-Message-State: ALoCoQmf7hC1eMWqFwMDMHyecujmBKAzp68jpC0d6WUnrkNmNh+oa8Oo0IPzEQK2LJ5utn8SqwrA X-Received: by 10.112.125.33 with SMTP id mn1mr109485lbb.43.1390687631864; Sat, 25 Jan 2014 14:07:11 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.129.170 with HTTP; Sat, 25 Jan 2014 14:06:51 -0800 (PST) In-Reply-To: <52E42A1B.3040907@rewt.org.uk> References: <52E42A1B.3040907@rewt.org.uk> From: Juli Mallett Date: Sat, 25 Jan 2014 14:06:51 -0800 X-Google-Sender-Auth: ZrgCg1OGZsb6TrNonjp0dDUMC8k Message-ID: Subject: Re: More trapframe panics To: Joe Holden Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-mips@freebsd.org" 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: Sat, 25 Jan 2014 22:07:20 -0000 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 =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" >