From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 21:57:54 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 952CF159; Mon, 27 Jan 2014 21:57:54 +0000 (UTC) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 90F011575; Mon, 27 Jan 2014 21:57:52 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.7/8.14.7) with ESMTP id s0RLvpCu058894; Mon, 27 Jan 2014 15:57:51 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.7/8.14.7/Submit) id s0RLvow6058893; Mon, 27 Jan 2014 15:57:50 -0600 (CST) (envelope-from brooks) Date: Mon, 27 Jan 2014 15:57:50 -0600 From: Brooks Davis To: Juli Mallett Subject: Re: More trapframe panics Message-ID: <20140127215750.GH8857@lor.one-eyed-alien.net> References: <52E42A1B.3040907@rewt.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iFRdW5/EC4oqxDHL" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "sson@freebsd.org 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: Mon, 27 Jan 2014 21:57:54 -0000 --iFRdW5/EC4oqxDHL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 25, 2014 at 02:06:51PM -0800, Juli Mallett wrote: > On Sat, Jan 25, 2014 at 1:18 PM, Joe Holden wrote: >=20 > > Hi, > > >=20 >=20 > > Just chucked 10.0-R onto an ERL here, already hit a trapframe panic when > > building several ports, IIRC these were fixed before? > > >=20 > 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 sav= ed > 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. >=20 > panic: kernel stack overflow - trapframe at 0xffffffff80753eb0 > > >=20 > 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 acti= on > going forward. >=20 > 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 remin= ds > 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 putti= ng > effort in to reporting these, since resolution is probably going to be > elusive, or at least indirect. Stacey has implemented a change to double the kernel stack size to 16K by adding a another wired TLB entry. It is sufficient to let us use NFS on CHERI (which has much bigger context due to another 32 256-bit registers). The changes are in the CheriBSD github: https://github.com/CTSRD-CHERI/cheribsd/commit/8db80374b098414b0435352eef54= b5afefe18d90 https://github.com/CTSRD-CHERI/cheribsd/commit/a9ae6dc7bb65457fe4732c19c71e= 8d30541643fe https://github.com/CTSRD-CHERI/cheribsd/commit/efd25472a36b9aed6910e630661a= 4a296a88f5f8 I think we're leaning toward switching the stack to larger pages as the longer term solution to avoid wasting TLB entries. -- Brooks --iFRdW5/EC4oqxDHL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFS5tZcXY6L6fI4GtQRAoyKAKDeLvWVQWtXmLc9xE8rDLqRY3pK3ACdHy8S blAxw+G5KOXIqWRlrimwww4= =MDCT -----END PGP SIGNATURE----- --iFRdW5/EC4oqxDHL--