Date: Mon, 27 Jan 2014 15:57:50 -0600 From: Brooks Davis <brooks@freebsd.org> To: Juli Mallett <jmallett@FreeBSD.org> Cc: "sson@freebsd.org freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: More trapframe panics Message-ID: <20140127215750.GH8857@lor.one-eyed-alien.net> 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
--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 <lists@rewt.org.uk> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140127215750.GH8857>