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? From owner-freebsd-mips@FreeBSD.ORG Sun Jan 26 16:05:17 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 AE33FD71 for ; Sun, 26 Jan 2014 16:05:17 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 340E11232 for ; Sun, 26 Jan 2014 16:05:16 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id b8so3775894lan.4 for ; Sun, 26 Jan 2014 08:05:08 -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=478u6RjFicKdVuPuYBpK+ymHLEQan4td7gyBSAsxiO0=; b=Tb/CvWa04Fs0v2znCfyAMi70vocpNbQ6HcA+EbJGZ19lzX5sLb2/QyO35ked04I7NB 0z1SsABMoTyCe4miXBtwf5maZyh92sINaBspbhKxJEDLtzHeZ9Ysvz2T7TBDscxzIRaO jkcpKZKTl+aGE93wFukYQztaeExpEtcSahbI4Ox9z4Z5EsU2ZzJCkT3jEeAnoyec/yrD IIfpWpXWVvEDRVoa/blqQXxjuBmUWnUc1ArzclC2Tt8hv3iN3NfjMtUZQQrDZ/fYftY5 mdo6B8r+TNNy7klLbvqUyOF2xhnrEpl2qUU/HUsb4B/3jcDr4LjyEdHr5l7luGlVsrU6 9Zbg== X-Gm-Message-State: ALoCoQkKoaXBwJHEty5FfJF7PTpAHuwzhoM0XSpoUZRnpGsPBVkZLGpEl4wORZokA0vtZigbDIHK X-Received: by 10.152.161.234 with SMTP id xv10mr17874lab.41.1390752308806; Sun, 26 Jan 2014 08:05:08 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.129.170 with HTTP; Sun, 26 Jan 2014 08:04:48 -0800 (PST) In-Reply-To: <52E524BD.7090106@rlwinm.de> References: <52E42A1B.3040907@rewt.org.uk> <52E524BD.7090106@rlwinm.de> From: Juli Mallett Date: Sun, 26 Jan 2014 08:04:48 -0800 X-Google-Sender-Auth: YbK7H_380gXKFN1TfNTVP3FBBV0 Message-ID: Subject: Re: More trapframe panics To: Jan Bramkamp Content-Type: text/plain; charset=UTF-8 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: Sun, 26 Jan 2014 16:05:17 -0000 On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp wrote: > > 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? That's exactly what needs to happen in all 64-bit MIPS kernels. Unlike some other architectures, KSTACK_PAGES cannot simply be increased, however. All of the code which handles loading the kernel stack and keeping it mapped, etc., assumes that it takes up exactly one TLB entry, i.e. 2 pages. One could simply double KSTACK_PAGES for 64-bit builds and modify the code to support the case of 2 or 4 pages, which would keep the code as gross as it is today and not buy much flexibility, but might be worthwhile as a short-term fix. Being able to support arbitrary values of KSTACK_PAGES (or at least arbitrary multiples of 2 up to the maximum number of wired TLB entries times 2) would be better. Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Sun Jan 26 18:54:14 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC166DB3 for ; Sun, 26 Jan 2014 18:54:14 +0000 (UTC) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DAD61102 for ; Sun, 26 Jan 2014 18:54:14 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id k19so7103961igc.5 for ; Sun, 26 Jan 2014 10:54:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KLV/w5oNLM2/jUvQHYaqa+QumNnBH/fZKwKErF26iXU=; b=YWaWjSWSFHAeJgE9ss2KTH5cbASPUYub9Ek+K/0l1uYHLjKEfMiEm4hV+GUXvFZB9V GeWUT1PSCvlc8oI1L8MAaK9HeRK3sN1d14YizqcYoyjc+9QdjGOlI4Y8Ja0ApwagBOLM BbZdB0K/Bsqof0N47JB7KzfhKaFk7qIvWNcRW3CLYvEgb1Xa1MtdK/Iil2GaQv3J7wnT PJjv6fQBJaS5GmLaljYYBgQ3s5HLomy9bUZIrrfVXg+qAiujfjCs6gEmeMRydtfxjavW rQTtV2wJ8raccLxqxmf/flwd7+U89RKI57jnolyjT/xm32YZ+YhO8jnoiekWpoa8JGIt 5CEQ== X-Gm-Message-State: ALoCoQnYsSv6LMTOi3NW1+fExz+RdrPGlvqRxLKLKHZM+RMJqONgjdZyWYan7uTJz0hh+2iA0czG X-Received: by 10.51.15.130 with SMTP id fo2mr14111284igd.28.1390762447484; Sun, 26 Jan 2014 10:54:07 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ac3sm35554067igd.4.2014.01.26.10.54.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 10:54:06 -0800 (PST) Sender: Warner Losh Subject: Re: More trapframe panics Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 26 Jan 2014 11:54:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> References: <52E42A1B.3040907@rewt.org.uk> <52E524BD.7090106@rlwinm.de> To: Juli Mallett X-Mailer: Apple Mail (2.1085) 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: Sun, 26 Jan 2014 18:54:14 -0000 On Jan 26, 2014, at 9:04 AM, Juli Mallett wrote: > On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp wrote: >>=20 >> 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? >=20 >=20 > That's exactly what needs to happen in all 64-bit MIPS kernels. = Unlike > some other architectures, KSTACK_PAGES cannot simply be increased, > however. All of the code which handles loading the kernel stack and > keeping it mapped, etc., assumes that it takes up exactly one TLB = entry, > i.e. 2 pages. One could simply double KSTACK_PAGES for 64-bit builds = and > modify the code to support the case of 2 or 4 pages, which would keep = the > code as gross as it is today and not buy much flexibility, but might = be > worthwhile as a short-term fix. Being able to support arbitrary = values of > KSTACK_PAGES (or at least arbitrary multiples of 2 up to the maximum = number > of wired TLB entries times 2) would be better. I hacked together a kludge that quadrupled this by going to the next = larger page size for stack pages in the TLB, but hit something ugly when = I did that... But I've lost that code, so maybe I should try again to = see if I'm more clever the second time. This is one of the things that makes it hard to have a nice native build = server on mips64... Warner From owner-freebsd-mips@FreeBSD.ORG Sun Jan 26 23:37:12 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 E38BEC31 for ; Sun, 26 Jan 2014 23:37:12 +0000 (UTC) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66E4317AB for ; Sun, 26 Jan 2014 23:37:11 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id u14so4021570lbd.29 for ; Sun, 26 Jan 2014 15:37:04 -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=QVWP9YCfbr+7PKdHKBxUfC6qSYB94BeA1aFrJqvA2Rw=; b=eBMw2ZFbkzh0UiJAraTmF/FNmkWAO68NlVFVg9o1E6nBfCj/S3ZDpPaLv2Bb6FW/cY bR2uIAUnVDVKTSUibuDCjWl4g4LHcsN2kFyX9YjyVRmxpcG72iIIZh7uguqlYwhggoez twYBqxbw3R9/nkSh0w4H9mzoKKv8x9ZB8a7BvRq72BTE/b1XTpRDaw9tW4fpYnrh5nGW qKJnFixW+TwFoIme1TG99LTpAG23LRHHHlJULz2cKr7eIhMVe9bnNV16htucTVRwutJs XpqB1niudshSJFOfy68QhXcnXFo2Ei581/69O6OBTQXafFeVQ/rAwV03ir0kR5VWkgKe s6Jg== X-Gm-Message-State: ALoCoQnWjZZnTJ/pzRr0T4ga6Q5MW8ay/YJtOagLjOsh9wCQ5iWZiLy3ilDiwrvnMYI0LyOg0mfK X-Received: by 10.152.43.103 with SMTP id v7mr226993lal.46.1390779078269; Sun, 26 Jan 2014 15:31:18 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.129.170 with HTTP; Sun, 26 Jan 2014 15:30:58 -0800 (PST) In-Reply-To: <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> References: <52E42A1B.3040907@rewt.org.uk> <52E524BD.7090106@rlwinm.de> <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> From: Juli Mallett Date: Sun, 26 Jan 2014 15:30:58 -0800 X-Google-Sender-Auth: HJ_6pF84C7fpzP18QOIUibRa_5Y Message-ID: Subject: Re: More trapframe panics To: Warner Losh Content-Type: text/plain; charset=UTF-8 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: Sun, 26 Jan 2014 23:37:13 -0000 Robert Watson and someone else (IIRC) discouraged going this route as some CPUs do not actually support every PageMask value specified for the R4K, so it would turn into an implementation/maintenance nightmare. Being able to fill an arbitrary number of TLB entries with kernel stack seems just better, anyway, for, I dunno, the person who wants to run Python in the kernel or something :) On Sun, Jan 26, 2014 at 10:54 AM, Warner Losh wrote: > > On Jan 26, 2014, at 9:04 AM, Juli Mallett wrote: > > > On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp wrote: > >> > >> 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? > > > > > > That's exactly what needs to happen in all 64-bit MIPS kernels. Unlike > > some other architectures, KSTACK_PAGES cannot simply be increased, > > however. All of the code which handles loading the kernel stack and > > keeping it mapped, etc., assumes that it takes up exactly one TLB entry, > > i.e. 2 pages. One could simply double KSTACK_PAGES for 64-bit builds and > > modify the code to support the case of 2 or 4 pages, which would keep the > > code as gross as it is today and not buy much flexibility, but might be > > worthwhile as a short-term fix. Being able to support arbitrary values > of > > KSTACK_PAGES (or at least arbitrary multiples of 2 up to the maximum > number > > of wired TLB entries times 2) would be better. > > I hacked together a kludge that quadrupled this by going to the next > larger page size for stack pages in the TLB, but hit something ugly when I > did that... But I've lost that code, so maybe I should try again to see if > I'm more clever the second time. > > This is one of the things that makes it hard to have a nice native build > server on mips64... > > Warner > > From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 01:04:56 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 A0FC25C4 for ; Mon, 27 Jan 2014 01:04:56 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 655A11EA6 for ; Mon, 27 Jan 2014 01:04:55 +0000 (UTC) Received: from [10.193.246.16] (unknown [91.208.177.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lhr1.as41113.net (Postfix) with ESMTPS id 3fCCRL36NQz7vXM for ; Mon, 27 Jan 2014 01:04:46 +0000 (UTC) Message-ID: <52E5B0AE.7030106@rewt.org.uk> Date: Mon, 27 Jan 2014 01:04:46 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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> <52E524BD.7090106@rlwinm.de> <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> In-Reply-To: <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 01:04:56 -0000 On 26/01/2014 18:54, Warner Losh wrote: > > On Jan 26, 2014, at 9:04 AM, Juli Mallett wrote: > >> On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp wrote: >>> >>> 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? >> >> >> That's exactly what needs to happen in all 64-bit MIPS kernels. Unlike >> some other architectures, KSTACK_PAGES cannot simply be increased, >> however. All of the code which handles loading the kernel stack and >> keeping it mapped, etc., assumes that it takes up exactly one TLB entry, >> i.e. 2 pages. One could simply double KSTACK_PAGES for 64-bit builds and >> modify the code to support the case of 2 or 4 pages, which would keep the >> code as gross as it is today and not buy much flexibility, but might be >> worthwhile as a short-term fix. Being able to support arbitrary values of >> KSTACK_PAGES (or at least arbitrary multiples of 2 up to the maximum number >> of wired TLB entries times 2) would be better. > > I hacked together a kludge that quadrupled this by going to the next larger page size for stack pages in the TLB, but hit something ugly when I did that... But I've lost that code, so maybe I should try again to see if I'm more clever the second time. > > This is one of the things that makes it hard to have a nice native build server on mips64... > > Warner > I have plenty of hardware (pretty much just spare ERLs) that you can use if you want - unless you can give me some ideas on other mips64 hardware that would be useful in which case I can make that available too. From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 01:06:31 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 721CA681 for ; Mon, 27 Jan 2014 01:06:31 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 337631EB3 for ; Mon, 27 Jan 2014 01:06:30 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id at1so5186281iec.11 for ; Sun, 26 Jan 2014 17:06:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=P4vZgWgUM+v046MfV1J2L+Ux0QHBK1O8ktbcMKCZ+Zo=; b=aqW/68dVnFxrsYp4dmAuq9kCnIXTmhvF9Yb1nprwaVVHSitmuxWx6vrKyJoMNDcDla 0eu0+hKvfU40GCJSXMoX54jXlLdzpC00exuLRwIJjFIaZ+BV9giahaDyDiJC++/90P+z Dbg/vLiW75xmlEQ62zpCMVbg25E3Pxi7ChwZ1Vy73PphhwQ+lLvRLiOVjz+X9yppHZvf /u88hQN4nKLEpQOSmvioueS/qFTOAlbErQLbWLzakWzWLLUs3XDBxmzLD+5yrcxRtFQu wEaVElplIdEzqmveey6a2oCjPxBfjryZb9OQJJ8Fnr7emdow37wJrG7UjVSFDfXxn0MW plIA== X-Gm-Message-State: ALoCoQn5T3XUITd/8kYsxQ+/dkZTEP+9kaeR9LBFPXjH3oSmzC+jwBcdZieXwajsWPJ6nrYjV0Ei X-Received: by 10.51.17.71 with SMTP id gc7mr15023987igd.12.1390784784143; Sun, 26 Jan 2014 17:06:24 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qb3sm37366780igb.7.2014.01.26.17.06.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 17:06:23 -0800 (PST) Sender: Warner Losh Subject: Re: More trapframe panics Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 26 Jan 2014 18:06:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52E42A1B.3040907@rewt.org.uk> <52E524BD.7090106@rlwinm.de> <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> To: Juli Mallett X-Mailer: Apple Mail (2.1085) 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: Mon, 27 Jan 2014 01:06:31 -0000 Yea, I'm aware of the issues. I was hoping for a quick patch to make my = Cavium machines better since I know this is an optional feature of the = R4k spec. At the time I had my head wrapped around this, it seemed like = a faster path, but there were snags in non-uniform page sizes and alias = avoidance that make make this untenable anyway... Warner On Jan 26, 2014, at 4:30 PM, Juli Mallett wrote: > Robert Watson and someone else (IIRC) discouraged going this route as = some CPUs do not actually support every PageMask value specified for the = R4K, so it would turn into an implementation/maintenance nightmare. = Being able to fill an arbitrary number of TLB entries with kernel stack = seems just better, anyway, for, I dunno, the person who wants to run = Python in the kernel or something :) >=20 >=20 > On Sun, Jan 26, 2014 at 10:54 AM, Warner Losh wrote: >=20 > On Jan 26, 2014, at 9:04 AM, Juli Mallett wrote: >=20 > > On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp = wrote: > >> > >> 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? > > > > > > That's exactly what needs to happen in all 64-bit MIPS kernels. = Unlike > > some other architectures, KSTACK_PAGES cannot simply be increased, > > however. All of the code which handles loading the kernel stack and > > keeping it mapped, etc., assumes that it takes up exactly one TLB = entry, > > i.e. 2 pages. One could simply double KSTACK_PAGES for 64-bit = builds and > > modify the code to support the case of 2 or 4 pages, which would = keep the > > code as gross as it is today and not buy much flexibility, but might = be > > worthwhile as a short-term fix. Being able to support arbitrary = values of > > KSTACK_PAGES (or at least arbitrary multiples of 2 up to the maximum = number > > of wired TLB entries times 2) would be better. >=20 > I hacked together a kludge that quadrupled this by going to the next = larger page size for stack pages in the TLB, but hit something ugly when = I did that... But I've lost that code, so maybe I should try again to = see if I'm more clever the second time. >=20 > This is one of the things that makes it hard to have a nice native = build server on mips64... >=20 > Warner >=20 >=20 From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 02:49:18 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 F18AB266 for ; Mon, 27 Jan 2014 02:49:17 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id B429C1507 for ; Mon, 27 Jan 2014 02:49:17 +0000 (UTC) Received: from [10.193.246.16] (unknown [91.208.177.70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lhr1.as41113.net (Postfix) with ESMTPS id 3fCFlr6PRbz7vXM for ; Mon, 27 Jan 2014 02:49:12 +0000 (UTC) Message-ID: <52E5C925.40707@rewt.org.uk> Date: Mon, 27 Jan 2014 02:49:09 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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> <52E524BD.7090106@rlwinm.de> <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 02:49:18 -0000 If one doesn't try to compile multiple ports at once, it seems to behave.. although I'm having trouble stess testing it at the moment since national grid seem to think supplying 0-270V to my house is acceptable (some fault or something) :P On 27/01/2014 01:06, Warner Losh wrote: > Yea, I'm aware of the issues. I was hoping for a quick patch to make my Cavium machines better since I know this is an optional feature of the R4k spec. At the time I had my head wrapped around this, it seemed like a faster path, but there were snags in non-uniform page sizes and alias avoidance that make make this untenable anyway... > > Warner > > On Jan 26, 2014, at 4:30 PM, Juli Mallett wrote: > >> Robert Watson and someone else (IIRC) discouraged going this route as some CPUs do not actually support every PageMask value specified for the R4K, so it would turn into an implementation/maintenance nightmare. Being able to fill an arbitrary number of TLB entries with kernel stack seems just better, anyway, for, I dunno, the person who wants to run Python in the kernel or something :) >> >> >> On Sun, Jan 26, 2014 at 10:54 AM, Warner Losh wrote: >> >> On Jan 26, 2014, at 9:04 AM, Juli Mallett wrote: >> >>> On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp wrote: >>>> >>>> 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? >>> >>> >>> That's exactly what needs to happen in all 64-bit MIPS kernels. Unlike >>> some other architectures, KSTACK_PAGES cannot simply be increased, >>> however. All of the code which handles loading the kernel stack and >>> keeping it mapped, etc., assumes that it takes up exactly one TLB entry, >>> i.e. 2 pages. One could simply double KSTACK_PAGES for 64-bit builds and >>> modify the code to support the case of 2 or 4 pages, which would keep the >>> code as gross as it is today and not buy much flexibility, but might be >>> worthwhile as a short-term fix. Being able to support arbitrary values of >>> KSTACK_PAGES (or at least arbitrary multiples of 2 up to the maximum number >>> of wired TLB entries times 2) would be better. >> >> I hacked together a kludge that quadrupled this by going to the next larger page size for stack pages in the TLB, but hit something ugly when I did that... But I've lost that code, so maybe I should try again to see if I'm more clever the second time. >> >> This is one of the things that makes it hard to have a nice native build server on mips64... >> >> Warner >> >> > > _______________________________________________ > 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" > From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 04:28:35 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 59DBA60D; Mon, 27 Jan 2014 04:28:35 +0000 (UTC) Received: from fallback2.mail.ru (fallback2.mail.ru [94.100.176.87]) by mx1.freebsd.org (Postfix) with ESMTP id C5BC01D2C; Mon, 27 Jan 2014 04:28:34 +0000 (UTC) Received: from f107.i.mail.ru (f107.i.mail.ru [94.100.178.76]) by fallback2.mail.ru (mPOP.Fallback_MX) with ESMTP id 57CDFFCB22AA; Mon, 27 Jan 2014 08:28:33 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:Mime-Version:Subject:Cc:To:From; bh=H/J056tz68l1IVjVcTCvO95hOCVlnJzWBrJ8VWozTu4=; b=ZBB2Q0m+MYErQnoiM8xZLWdDV7biqCQFYAm9heFaXT6uBa0fwzZIwEAYNlA2rUWYjhVKDmW19vDfQoafa2AJPyj7Elk6Wtt9nhzhF1LPLBZ5VhvjAd6/L+PFKqj01LU/OuRimjR1xyMbfhXm0+x/U8EnFNSn9UsbphJFHZX3sW8=; Received: from mail by f107.i.mail.ru with local (envelope-from ) id 1W7do8-0006Qq-OF; Mon, 27 Jan 2014 08:28:24 +0400 Received: from [81.222.108.121] by e.mail.ru with HTTP; Mon, 27 Jan 2014 08:28:24 +0400 From: =?UTF-8?B?QW50b24=?= To: =?UTF-8?B?THVpeiBPdGF2aW8gTyBTb3V6YQ==?= Subject: =?UTF-8?B?UmVbOF06IFJCNDUwRyBjb21waWxpbmcgdGhlIGtlcm5lbA==?= Mime-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [81.222.108.121] Date: Mon, 27 Jan 2014 08:28:24 +0400 X-Priority: 3 (Normal) Message-ID: <1390796904.72635309@f107.i.mail.ru> X-Mras: Ok X-Spam: undefined In-Reply-To: References: <1388404360.131024714@f310.i.mail.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: =?UTF-8?B?XFxcXFxcZnJlZWJzZC1taXBzQGZyZWVic2Qub3JnXFxcXFxc?= X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: =?UTF-8?B?QW50b24=?= List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 04:28:35 -0000 CkhpIEx1aXosIAoKWW91ciBrZXJuZWwgYnVpbGRzIGFuZCBydW5zIGZpbmUuIApJIHdpbGwgdGVz dCBpdCBmb3IgYSB3aGlsZSB1bmRlciBsb2FkLCBidXQgSSdtIHN1cmUgZXZlcnl0aGluZyB3aWxs IGJlIGdvb2QuCgoK0KfQtdGC0LLQtdGA0LMsIDIzINGP0L3QstCw0YDRjyAyMDE0LCAxMToyNSAt MDI6MDAg0L7RgiBMdWl6IE90YXZpbyBPIFNvdXphIDxsaXN0cy5ickBnbWFpbC5jb20+Ogo+T24g NSBKYW51YXJ5IDIwMTQgMjM6NDEsIEFkcmlhbiBDaGFkZCA8IGFkcmlhbkBmcmVlYnNkLm9yZyA+ IHdyb3RlOgo+PiBPbiA1IEphbnVhcnkgMjAxNCAwMjoxNywgQW50b24gPCBmZWxpeF9tYWlsQG1h aWwucnUgPiB3cm90ZToKPj4+IEhpIEFkcmlhbiwKPj4+Cj4+PiBJIGNhbiBwb3N0IG15IGtlcm5l bCBjb25maWdzIGFmdGVyIGEgd2Vlay4gSWYgaXQncyBuZWVkZWQuCj4KPgo+U29ycnkgZm9yIGp1 bXAgaW4gc28gbGF0ZS4gSSd2ZSBhIHdvcmtpbmcga2VybmVsIGFuZCBoaW50cyBmb3IgUkI0NTBH Lgo+UGxlYXNlIHRyeSB0aGUgYXR0YWNoZWQgZmlsZXMgKGFuZCBhcHBseSB0aGUgdHdvIHBhdGNo ZXMpLgo+Cj5MZXQgbWUga25vdyBpZiBpdCB3b3JrcyBmb3IgeW91Lgo+Cj5SQjQ1MEcgZG1lc2c6 ICBodHRwOi8vcGFzdGViaW4uY2EvMjU3NzYzNQo+Cj5MdWl6Cj4KCg== From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 06:40:09 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ABFA875 for ; Mon, 27 Jan 2014 06:40:09 +0000 (UTC) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E4F6515FD for ; Mon, 27 Jan 2014 06:40:08 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id ar20so5422584iec.38 for ; Sun, 26 Jan 2014 22:40:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NFBcfkZf4YwHOKE5iMise9FAvM+gF6AIuK9P82yOvtA=; b=Au6lg1MSof49dY8WCtuHKjNifdzQl3gYX/d7guIWeF2c/zzgNSgomcyGLGcP3ASb8v bvrGbAfDKJbpcq9ounUa499lsazwRhxqj+UZXAEONY0Gs7qOi/xxkbWFVDOGFPpfJPz/ fSz/OV6ulbgEJvLjgICgD5MtBm17Gd50yID7v5ogn9y+mU/R1CZFkmla+BqXfjmqncw9 34pIfHU/H74MBj0+9Q7l+Vv9+3Hz+52lIjVk/lhT1ff6Z0f2SLVkj4Jmabg8Qxfjct/i YgXojOKVkvgMmuzQR+oYXC3sI7HGq4NLe2gOOb3FLT/CJ8D6pTxNGNIXNsZuUpC0zcE9 8S4A== X-Gm-Message-State: ALoCoQnTMESLdIzThwGsMd1FuWvwy80fooVjURWrReTGJH2dHiDzCVYY/w3exV7YI4S4JVRAYfUS X-Received: by 10.50.136.165 with SMTP id qb5mr16204650igb.2.1390804802260; Sun, 26 Jan 2014 22:40:02 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id l7sm40114839igx.2.2014.01.26.22.40.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 22:40:01 -0800 (PST) Sender: Warner Losh Subject: Re: More trapframe panics Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <52E5C925.40707@rewt.org.uk> Date: Sun, 26 Jan 2014 23:40:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52E42A1B.3040907@rewt.org.uk> <52E524BD.7090106@rlwinm.de> <453F8F8F-41E5-4640-9683-5A8553AB0822@bsdimp.com> <52E5C925.40707@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1085) 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: Mon, 27 Jan 2014 06:40:09 -0000 There are some ports that just trigger it built single threaded and only = that port, which is why I was looking for a quick and dirty hack... I = fear that Juli is right, though, and a real fix is needed.... Warner On Jan 26, 2014, at 7:49 PM, Joe Holden wrote: > If one doesn't try to compile multiple ports at once, it seems to = behave.. although I'm having trouble stess testing it at the moment = since national grid seem to think supplying 0-270V to my house is = acceptable (some fault or something) :P >=20 > On 27/01/2014 01:06, Warner Losh wrote: >> Yea, I'm aware of the issues. I was hoping for a quick patch to make = my Cavium machines better since I know this is an optional feature of = the R4k spec. At the time I had my head wrapped around this, it seemed = like a faster path, but there were snags in non-uniform page sizes and = alias avoidance that make make this untenable anyway... >>=20 >> Warner >>=20 >> On Jan 26, 2014, at 4:30 PM, Juli Mallett wrote: >>=20 >>> Robert Watson and someone else (IIRC) discouraged going this route = as some CPUs do not actually support every PageMask value specified for = the R4K, so it would turn into an implementation/maintenance nightmare. = Being able to fill an arbitrary number of TLB entries with kernel stack = seems just better, anyway, for, I dunno, the person who wants to run = Python in the kernel or something :) >>>=20 >>>=20 >>> On Sun, Jan 26, 2014 at 10:54 AM, Warner Losh = wrote: >>>=20 >>> On Jan 26, 2014, at 9:04 AM, Juli Mallett wrote: >>>=20 >>>> On Sun, Jan 26, 2014 at 7:07 AM, Jan Bramkamp = wrote: >>>>>=20 >>>>> 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? >>>>=20 >>>>=20 >>>> That's exactly what needs to happen in all 64-bit MIPS kernels. = Unlike >>>> some other architectures, KSTACK_PAGES cannot simply be increased, >>>> however. All of the code which handles loading the kernel stack = and >>>> keeping it mapped, etc., assumes that it takes up exactly one TLB = entry, >>>> i.e. 2 pages. One could simply double KSTACK_PAGES for 64-bit = builds and >>>> modify the code to support the case of 2 or 4 pages, which would = keep the >>>> code as gross as it is today and not buy much flexibility, but = might be >>>> worthwhile as a short-term fix. Being able to support arbitrary = values of >>>> KSTACK_PAGES (or at least arbitrary multiples of 2 up to the = maximum number >>>> of wired TLB entries times 2) would be better. >>>=20 >>> I hacked together a kludge that quadrupled this by going to the next = larger page size for stack pages in the TLB, but hit something ugly when = I did that... But I've lost that code, so maybe I should try again to = see if I'm more clever the second time. >>>=20 >>> This is one of the things that makes it hard to have a nice native = build server on mips64... >>>=20 >>> Warner >>>=20 >>>=20 >>=20 >> _______________________________________________ >> 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" >>=20 >=20 > _______________________________________________ > 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" From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 07:06:06 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20962CB1; Mon, 27 Jan 2014 07:06:06 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7270A17A1; Mon, 27 Jan 2014 07:06:05 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id w7so4223507lbi.27 for ; Sun, 26 Jan 2014 23:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7OxZaQm47vimu6MI01OAWjkuYbLtLheC/4UQjaAUhA8=; b=WGaI+psmuDOGtR1+1A+czyxU31DTSWbOpPZXJcVGJcoEusYMrPuFEBcN6M/qfezPGE P5oSBvc1NCykHSjtR3nD74XgAA25m/eLUu7EHkEEkMgw+ytVnlO7/NY4VqeynPmatrrI nCLRiDsYohMreaXyF7tWDuYc82K2LfhnGeZXkR286NY4sKTUKgG5l0bvc5RGrtfQPOOm g8kSqcDirWI+TNpiCzVg69M3RTyGyBzVYpa32FPjGU0lBoCf8Z5QTKUR0LXZt+kbhePq F7toWa24C8xA0yOSSM7CbA5410SkNB1lgF2xcUZ8eOyS/NRfnEf0f4eWuE2J70VBu+8h wggQ== MIME-Version: 1.0 X-Received: by 10.152.143.41 with SMTP id sb9mr1328637lab.21.1390806363433; Sun, 26 Jan 2014 23:06:03 -0800 (PST) Received: by 10.112.234.166 with HTTP; Sun, 26 Jan 2014 23:06:03 -0800 (PST) In-Reply-To: References: <52E42A1B.3040907@rewt.org.uk> Date: Mon, 27 Jan 2014 12:36:03 +0530 Message-ID: Subject: Re: More trapframe panics From: "Jayachandran C." To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 27 Jan 2014 07:06:06 -0000 Hi Juli, On Sun, Jan 26, 2014 at 3:36 AM, Juli Mallett wrote: > > 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. I had not seen the issue so far. When I had done the pmap changes ealier, I had thought of adding the option to use a higher order page for kernel stack and using the KSEG0 address as the stack pointer, instead of using the wired entry as we do now. Is there any reason this will not work. JC. From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 07:20:13 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 5D530FF9 for ; Mon, 27 Jan 2014 07:20:13 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C75D5188A for ; Mon, 27 Jan 2014 07:20:12 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id z5so4143882lbh.36 for ; Sun, 26 Jan 2014 23:20:04 -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=FXOt8SONHSQa06q9TcEO7hqS5oP/y4lqmk0eZcIxMsI=; b=TXwrC1QamkkFjuaLS3utTVpx7aB3SnKtRx9fzkK5cvulLnUuDX19q9WHbyF0XSg1Ik fVsrS0y8LRTpIvJHQBXl+Gl8ZLkl/i+uWfImv4m5W6hRxqxjC5ZopMjzKeUSbgK5xIWu VPiK47kI/o1x/g6juEtnIMYyH/1sWkYOnIhyMXd0I0ud4x7SkKM9iT336PjJS7jYdyPl Gr4cy5ijy0Ndhz8SYOof2wo47wxQVujQI0sATVLhB/dpfZAcYNWZUonthjJOtZ7lQkFp e/9eIbhy3kVPMKkkAKdivre24BviuwObtfrmtCGTkNzerHDNuyxMEbGi2WkPaUGZ5b5k 1x2Q== X-Gm-Message-State: ALoCoQmmQfxIN95qpJWW//qDIz0O/fv1EaH4GJUchdjwfBOVHWz4Gz3AGn6R7xOVViB/8WBH/039 X-Received: by 10.112.236.3 with SMTP id uq3mr15727976lbc.14.1390807204683; Sun, 26 Jan 2014 23:20:04 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.152.129.170 with HTTP; Sun, 26 Jan 2014 23:19:44 -0800 (PST) In-Reply-To: References: <52E42A1B.3040907@rewt.org.uk> From: Juli Mallett Date: Sun, 26 Jan 2014 23:19:44 -0800 X-Google-Sender-Auth: yfCQkINrUir0LWz938-4ubwcVmo Message-ID: Subject: Re: More trapframe panics To: "Jayachandran C." Content-Type: text/plain; charset=UTF-8 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: Mon, 27 Jan 2014 07:20:13 -0000 On Sun, Jan 26, 2014 at 11:06 PM, Jayachandran C. wrote: > Hi Juli, > > On Sun, Jan 26, 2014 at 3:36 AM, Juli Mallett > wrote: > > > > 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. > > I had not seen the issue so far. > Honestly, I haven't seen it much either, certainly not as much as many people seem to report on the lists, and I built lots of packages, etc. But clearly my workload was different or something has changed in the kernel, but it's definitely a real problem. > When I had done the pmap changes ealier, I had thought of adding the > option to use a higher order page for kernel stack and using the KSEG0 > address as the stack pointer, instead of using the wired entry as we > do now. Is there any reason this will not work. I don't have a problem with physically-contiguous kernel stacks and use of KSEG0/XKPHYS. It's better in some ways, and I'd worry about a system on which finding 4 physically-contiguous pages was impossible. We can't swap out kstacks then, but that's probably okay. My major concern is that then a kernel stack overflow is probably a lot harder to detect, and an attacker probably has other interesting kernel data structures nearby. I'm sure there's other drawbacks to consider, but it'd simplify a lot of bad code, and it seems worthwhile as an intermediate step anyway, even if it does mean MIPS can't support guard pages for the kernel stack. To recapitulate other constraints for anyone who might be reading with interest, and on the off chance something useful shakes out: You really need the stack to be entirely within wired pages or you can take a fault which is unserviceable because you'll end up endlessly faulting for the kernel stack pointer if you hit the slow fault path and not just TLB refill, which is unfortunately not reliable on at least some CPUs. You could write very careful code to load the stack pointer from PCPU and bounds check sp and proceed very carefully, but I'm not sure we really want or need to go there. That said, it only matters for faults taken within the kernel; anything coming from userland including interrupts and syscalls will load sp and start at the top of the stack anyway, so you could at least avoid adding the overhead for the most performance-critical exception handlers. I know that on some CPUs we care about, having to use the extra wired TLB entry is a real pain. There are things we could do to lessen this pain, such as getting rid of the wired PCPU TLB entry. There's two possibilities I'd suggest for that, and only one of them relies on kstacks not being shared between CPUs: (1) Move to keeping the PCPU pointer in "gp". (2) Always store a PCPU pointer at the top of the kernel stack, adding a little indirection to load PCPU, but not a lot. It's nice to have the PCPU wired because you do want to be able to access it quickly from things like exception handlers, which gets messier with the "gp" approach, since then you have to load "gp" in some annoying manner when coming from userland. Just some thoughts. I'd be delighted to see any forward-moving approach that's actually taken :) Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 10:04:35 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 C5E6E446; Mon, 27 Jan 2014 10:04:35 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1F8551569; Mon, 27 Jan 2014 10:04:34 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id c11so4276586lbj.16 for ; Mon, 27 Jan 2014 02:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7l/r5UeFo9uM1XBFPoX8dfZGd789TVudp2QbGM52pLw=; b=orUcrJeay5Q8zoWOdo+EsLNbpoGAh1kwPHLPvi5xdu/ANkbeF78LSL/ZSJaQGOaNsB yf+M7fvAgMMNS3sdh0v0gseO9IcQ8k3BePuUOnJDtgnMeymp7P46DfO2Hws1X1w5pwKh Qwvm9u2DEc+gvgYM/4xrvuu6/va8F05nrbpphykDF+mowBes6+PHu2XQoP3yUdchV3Vt Mky75qa7TIy8lxHib9s9P1HgdgCP5QeFuQ4X/Rjt9/F5DmdXl2sGKo+L7j7/STq5C9aj +T0WpdtCsi3u12wCk3aCV5VZPBZgiJRSB8aWKGgakzcp3Eq8nvCmKfKOIqqlRzY+VJUH Fv3w== MIME-Version: 1.0 X-Received: by 10.152.120.37 with SMTP id kz5mr3959936lab.30.1390817073024; Mon, 27 Jan 2014 02:04:33 -0800 (PST) Received: by 10.112.234.166 with HTTP; Mon, 27 Jan 2014 02:04:32 -0800 (PST) In-Reply-To: References: <52E42A1B.3040907@rewt.org.uk> Date: Mon, 27 Jan 2014 15:34:32 +0530 Message-ID: Subject: Re: More trapframe panics From: "Jayachandran C." To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 27 Jan 2014 10:04:35 -0000 On Mon, Jan 27, 2014 at 12:49 PM, Juli Mallett wrote: > On Sun, Jan 26, 2014 at 11:06 PM, Jayachandran C. > wrote: >> >> Hi Juli, >> >> On Sun, Jan 26, 2014 at 3:36 AM, Juli Mallett >> wrote: >> > >> > 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. >> >> I had not seen the issue so far. > > > Honestly, I haven't seen it much either, certainly not as much as many > people seem to report on the lists, and I built lots of packages, etc. But > clearly my workload was different or something has changed in the kernel, > but it's definitely a real problem. It would be interesting to see the stacktrace when the overflow happens. If this is some specific driver or codepath, fixing that would be a better solution than to waste 8K per task. >> >> When I had done the pmap changes ealier, I had thought of adding the >> option to use a higher order page for kernel stack and using the KSEG0 >> address as the stack pointer, instead of using the wired entry as we >> do now. Is there any reason this will not work. > > I don't have a problem with physically-contiguous kernel stacks and use of > KSEG0/XKPHYS. It's better in some ways, and I'd worry about a system on > which finding 4 physically-contiguous pages was impossible. We can't swap > out kstacks then, but that's probably okay. My major concern is that then a > kernel stack overflow is probably a lot harder to detect, and an attacker > probably has other interesting kernel data structures nearby. I'm sure > there's other drawbacks to consider, but it'd simplify a lot of bad code, > and it seems worthwhile as an intermediate step anyway, even if it does mean > MIPS can't support guard pages for the kernel stack. Getting contiguous memory - maybe a custom UMA zone for kstack pages would be useful (although I have not really looked at this). And stack overflow detection: this will have to move to software if really needed. Or we should have a wired entry with a larger pagemask for the kstack page. > You could write very careful code to load the stack pointer from PCPU and > bounds check sp and proceed very carefully, but I'm not sure we really want > or need to go there. That said, it only matters for faults taken within the > kernel; anything coming from userland including interrupts and syscalls will > load sp and start at the top of the stack anyway, so you could at least > avoid adding the overhead for the most performance-critical exception > handlers. > > I know that on some CPUs we care about, having to use the extra wired TLB > entry is a real pain. There are things we could do to lessen this pain, > such as getting rid of the wired PCPU TLB entry. There's two possibilities > I'd suggest for that, and only one of them relies on kstacks not being > shared between CPUs: > > (1) Move to keeping the PCPU pointer in "gp". > (2) Always store a PCPU pointer at the top of the kernel stack, adding a > little indirection to load PCPU, but not a lot. > > It's nice to have the PCPU wired because you do want to be able to access it > quickly from things like exception handlers, which gets messier with the > "gp" approach, since then you have to load "gp" in some annoying manner when > coming from userland. I would like to move the PCPU out of wired entry as well. Using gp is one option. I wonder why we did not use the simpler option of having a array of pointers indexed by cpuid. Some MIPS processors also have COP0 kscratch registers. which can be used in a lot of theses cases. For example, we can keep the frequently used pointers like the current task's page table pointer, the current thread's kernel stack and current CPU's pcpu ptr in scratch. > Just some thoughts. I'd be delighted to see any forward-moving approach > that's actually taken :) The only unknown here would be to see how difficult it is to get a higher order page from the VM, and whether it will slow down task creation when the contiguous pages are not available. JC. From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 11:06:50 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 1879AC82 for ; Mon, 27 Jan 2014 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 00AAD1A8A for ; Mon, 27 Jan 2014 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0RB6n4o013059 for ; Mon, 27 Jan 2014 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0RB6nL8013057 for freebsd-mips@FreeBSD.org; Mon, 27 Jan 2014 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Jan 2014 11:06:49 GMT Message-Id: <201401271106.s0RB6nL8013057@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-mips@FreeBSD.org Subject: Current problem reports assigned to 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 11:06:50 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/177876 mips [mips] kernel stack overflow panic on mips64, EdgeRout o kern/165951 mips [ar913x] [ath] DDR flush isn't being done for the WMAC 2 problems total. From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 15:36:40 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C729F954 for ; Mon, 27 Jan 2014 15:36:40 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C9B91485 for ; Mon, 27 Jan 2014 15:36:40 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id e14so6004702iej.17 for ; Mon, 27 Jan 2014 07:36:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=c4ClYMYLYRwzOfoQVhDTyibwTPL6WefHrRkTdzSNDEM=; b=en/ELZ0Eq1ec3uZOInAJj1altJLrz55to1weJrIy4D96TMKoKr7SU5J/BU0XYtobGf EXhpdA/sshCaVNClm3Ri6bkFpYCxXMfVHqV7RKEytxDanCV0j8BxbCK3Q7Fo9fNhUqtr 2zPuDvtLSNgbcvGnxLx05r50mjz2kh9tcykiqOHiO4ZVZK72JeyKUYJf+fDESzCqWp5s 2ZZZ/OJsi02/1CIe+xYVSTz/7qZbHkJl3+J87iDl9ZhQaCJg9rYHW0vp/xGyqqkHpBbo NccFJ0fo2BjUnmL/ZtQAFV3ni8f+QODkmJzxvj+ApPxuHfLwwjaW5MtpQNG+XGAKZp/V Y96Q== X-Gm-Message-State: ALoCoQlMbrzQQxSFrOBWlY/OANu1Qy2X4Rg+QNVwQaUWVLlU8dQn0jMCpZwJGti9z704vD831uiS X-Received: by 10.42.129.9 with SMTP id o9mr5265411ics.38.1390836999215; Mon, 27 Jan 2014 07:36:39 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id d18sm45673720igz.0.2014.01.27.07.36.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 07:36:38 -0800 (PST) Sender: Warner Losh Subject: Re: More trapframe panics Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 27 Jan 2014 08:36:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> References: <52E42A1B.3040907@rewt.org.uk> To: "Jayachandran C." X-Mailer: Apple Mail (2.1085) 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: Mon, 27 Jan 2014 15:36:40 -0000 On Jan 27, 2014, at 3:04 AM, Jayachandran C. wrote: >=20 > It would be interesting to see the stacktrace when the overflow > happens. If this is some specific driver or codepath, fixing that > would be a better solution than to waste 8K per task. I get it when I try to build security/sudo from ports on a freshly built = -current. This was 100% reproducible in August or September (as well as = earlier) on a mips64 build on my both of my Octeon boards... Warner From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 15:46:17 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B563CEFF for ; Mon, 27 Jan 2014 15:46:17 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 7912A15B6 for ; Mon, 27 Jan 2014 15:46:17 +0000 (UTC) Received: from [10.16.240.11] (unknown [212.9.98.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.lhr1.as41113.net (Postfix) with ESMTPSA id 3fCb0Q5lpMz7vXM for ; Mon, 27 Jan 2014 15:46:14 +0000 (UTC) Message-ID: <52E67F45.20402@rewt.org.uk> Date: Mon, 27 Jan 2014 15:46:13 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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> <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> In-Reply-To: <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 15:46:17 -0000 On 27/01/2014 15:36, Warner Losh wrote: > > On Jan 27, 2014, at 3:04 AM, Jayachandran C. wrote: >> >> It would be interesting to see the stacktrace when the overflow >> happens. If this is some specific driver or codepath, fixing that >> would be a better solution than to waste 8K per task. > > I get it when I try to build security/sudo from ports on a freshly built -current. This was 100% reproducible in August or September (as well as earlier) on a mips64 build on my both of my Octeon boards... > > Warner > I *believe* mine was perl related, however I was building multiple ports at the same time so may not be one or the other... Building perl currently so will see if it blows up From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 15:51:12 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 B75412B5 for ; Mon, 27 Jan 2014 15:51:12 +0000 (UTC) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D5FD1663 for ; Mon, 27 Jan 2014 15:51:12 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id tp5so6009508ieb.35 for ; Mon, 27 Jan 2014 07:51:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=oqrbyai7qwFBtdrMgvFqMZ1+GPoetI0fGxWpO8JN2SQ=; b=AyuNrBrZ5nd1d6sPhrLarNpCTepQyhyTHOy7an8gIvmxXX/9NZuSvPPXMV3VnUavWg J8q2lc72iqEMrvFXzvsvaNtc4ekLj2IFE0GpNA9Mrnb2EWpqJU8RZ65TwaP8Q2Wz7f3U spGnKZNqQ0DHoSDErX9zZBQT1DH2bngBKCC2ioOcAXMEsxb8TUJb2an3AXZfiJDktOAr Ia8zEfuB1tbJGsIR3jLujHTXuY71pV/0xRfOKoo5xuVhorUC0di/gKomzQUVUmMCyK5L YUkYkckOv9nrI8Do4SmJDcDkumJNionJcc8CviB2Vai/HSYA1glbUz99DNgKPZGDjuRc Fe1w== X-Gm-Message-State: ALoCoQnRBylYYIPep5L8uBZ33kwusDAIXoTBMaTiKk1r9fWb7qVWBxda1YATGoXyD5BDPzBzaklK X-Received: by 10.50.194.131 with SMTP id hw3mr14498905igc.4.1390837866535; Mon, 27 Jan 2014 07:51:06 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id h6sm45763350igy.8.2014.01.27.07.51.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 07:51:06 -0800 (PST) Sender: Warner Losh Subject: Re: More trapframe panics Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <52E67F45.20402@rewt.org.uk> Date: Mon, 27 Jan 2014 08:51:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2912AEFA-AA0C-456A-A814-363478BFC900@bsdimp.com> References: <52E42A1B.3040907@rewt.org.uk> <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> <52E67F45.20402@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1085) 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: Mon, 27 Jan 2014 15:51:12 -0000 On Jan 27, 2014, at 8:46 AM, Joe Holden wrote: > On 27/01/2014 15:36, Warner Losh wrote: >>=20 >> On Jan 27, 2014, at 3:04 AM, Jayachandran C. wrote: >>>=20 >>> It would be interesting to see the stacktrace when the overflow >>> happens. If this is some specific driver or codepath, fixing that >>> would be a better solution than to waste 8K per task. >>=20 >> I get it when I try to build security/sudo from ports on a freshly = built -current. This was 100% reproducible in August or September (as = well as earlier) on a mips64 build on my both of my Octeon boards... >>=20 >> Warner >>=20 > I *believe* mine was perl related, however I was building multiple = ports at the same time so may not be one or the other... >=20 > Building perl currently so will see if it blows up Multiple ports at the same time shouldn't matter. This is a process = limit that's exceeded, not a global limit... Warner From owner-freebsd-mips@FreeBSD.ORG Mon Jan 27 17:03:02 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 E83C7904 for ; Mon, 27 Jan 2014 17:03:02 +0000 (UTC) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A298A1CC8 for ; Mon, 27 Jan 2014 17:03:02 +0000 (UTC) Received: by mail-qc0-f172.google.com with SMTP id c9so8477710qcz.31 for ; Mon, 27 Jan 2014 09:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3RfdmGnNAFui17uIWaU81/IuK9ymgyI2nXCx9/xjVT0=; b=X9arQWux7Ofqx9pUZrflGct1IB+mBxk6WWcUkeD5hVnkiZtW3n09cSZWk06RZ0h/MP dpiSc9t1xIBOemyIkzZyrsxEMZHd75lD6KsgL2bFM9t+qh247lilo0IboEKoYUowwAfM xSGNjAQLApFy/CnW5j04CwiPNOadgZ6xDkS4Hb5XxxixnA7pGdlVY5izFjcs1a6N3UpP 9y1SSmaorr/gC0s1mX/jC/zJAVvA2WtrLbVdZGLJt1dES+cruDwaKMoc94UJzScevt0P mWCDZH6Z+0LruVzCuKRDTXGxM0o6iTyfRjxLARhzKWypnGy8Kl+uXEKrL3I9O1eUhnGn sjCw== MIME-Version: 1.0 X-Received: by 10.140.96.180 with SMTP id k49mr41460567qge.4.1390842181826; Mon, 27 Jan 2014 09:03:01 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Mon, 27 Jan 2014 09:03:01 -0800 (PST) In-Reply-To: <2912AEFA-AA0C-456A-A814-363478BFC900@bsdimp.com> References: <52E42A1B.3040907@rewt.org.uk> <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> <52E67F45.20402@rewt.org.uk> <2912AEFA-AA0C-456A-A814-363478BFC900@bsdimp.com> Date: Mon, 27 Jan 2014 09:03:01 -0800 X-Google-Sender-Auth: LOj6_zfOzUeP1OEnPUiGKEXi5YU Message-ID: Subject: Re: More trapframe panics From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 27 Jan 2014 17:03:03 -0000 Hi joe, Can you post the backtrace? And resolve the symbol names for each of the stackframes that show up? It could be that there's some code doing dumb crap with stack frames that we can fix in the source. -a 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-- From owner-freebsd-mips@FreeBSD.ORG Tue Jan 28 10:09:20 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB123320; Tue, 28 Jan 2014 10:09:20 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 8BA6C1D2E; Tue, 28 Jan 2014 10:09:19 +0000 (UTC) Received: from [10.16.240.11] (unknown [212.9.98.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.lhr1.as41113.net (Postfix) with ESMTPSA id 3fD3T41FxSz7vbZ; Tue, 28 Jan 2014 10:09:12 +0000 (UTC) Message-ID: <52E781C6.2050308@rewt.org.uk> Date: Tue, 28 Jan 2014 10:09:10 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrian Chadd , Warner Losh Subject: Re: More trapframe panics References: <52E42A1B.3040907@rewt.org.uk> <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> <52E67F45.20402@rewt.org.uk> <2912AEFA-AA0C-456A-A814-363478BFC900@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 28 Jan 2014 10:09:20 -0000 On 27/01/2014 17:03, Adrian Chadd wrote: > Hi joe, > > Can you post the backtrace? And resolve the symbol names for each of > the stackframes that show up? > > It could be that there's some code doing dumb crap with stack frames > that we can fix in the source. > > > > -a > I'll try, wondering if this box also has ram problems as even though I regularly see page fault kernel messages on these, they don't usually lead to a userland crash. Always helpful when fsck leaves the filesystem in a worse state than it started because it crashed :D Will get debug kernel built and try and tickle it again, perl built fine in the end but libgcrypt upset it... is it worth applying those patches from CheriBSD? From owner-freebsd-mips@FreeBSD.ORG Wed Jan 29 08:33:54 2014 Return-Path: Delivered-To: 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 CA0E43A7; Wed, 29 Jan 2014 08:33:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E9191EE6; Wed, 29 Jan 2014 08:33:54 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id s0T8XmDl085684; Wed, 29 Jan 2014 03:33:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id s0T8XmUj085674; Wed, 29 Jan 2014 08:33:48 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 29 Jan 2014 08:33:48 GMT Message-Id: <201401290833.s0T8XmUj085674@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.17 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 08:33:54 -0000 TB --- 2014-01-29 07:49:44 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-29 07:49:44 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-29 07:49:44 - starting HEAD tinderbox run for mips/mips TB --- 2014-01-29 07:49:44 - cleaning the object tree TB --- 2014-01-29 07:49:44 - /usr/local/bin/svn stat /src TB --- 2014-01-29 07:49:52 - At svn revision 261254 TB --- 2014-01-29 07:49:53 - building world TB --- 2014-01-29 07:49:53 - CROSS_BUILD_TESTING=YES TB --- 2014-01-29 07:49:53 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-29 07:49:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-29 07:49:53 - SRCCONF=/dev/null TB --- 2014-01-29 07:49:53 - TARGET=mips TB --- 2014-01-29 07:49:53 - TARGET_ARCH=mips TB --- 2014-01-29 07:49:53 - TZ=UTC TB --- 2014-01-29 07:49:53 - __MAKE_CONF=/dev/null TB --- 2014-01-29 07:49:53 - cd /src TB --- 2014-01-29 07:49:53 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jan 29 07:50:01 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> cddl/usr.bin/ctfconvert (all) cc -O -pipe -G0 -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -std=gnu89 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-unknown-prag! mas -c /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/alist.c cc -O -pipe -G0 -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -std=gnu89 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-unknown-prag! mas -c /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctf.c cc -O -pipe -G0 -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -std=gnu89 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-unknown-prag! mas -c /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/ctfconvert.c cc -O -pipe -G0 -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -std=gnu89 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-unknown-prag! mas -c /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c cc1: warnings being treated as errors /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c: In function 'die_sou_create': /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:938: warning: unused variable 'bysz' *** Error code 1 Stop. bmake[4]: stopped in /src/cddl/usr.bin/ctfconvert *** Error code 1 Stop. bmake[3]: stopped in /src/cddl/usr.bin *** Error code 1 Stop. bmake[2]: stopped in /src/cddl *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-29 08:33:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-29 08:33:48 - ERROR: failed to build world TB --- 2014-01-29 08:33:48 - 1605.05 user 484.09 system 2643.46 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Wed Jan 29 16:21:26 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 AB8CADA9; Wed, 29 Jan 2014 16:21:26 +0000 (UTC) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by mx1.freebsd.org (Postfix) with ESMTP id DEA3E1B34; Wed, 29 Jan 2014 16:21:23 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=dq5Z+ic4 c=1 sm=0 a=Hbpc8ax9VmIgqBixU/K2CA==:17 a=dBRESv0yCI8A:10 a=ozSPa0bqj5AA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=KGjhK52YXX0A:10 a=vpU8xItVDkoA:10 a=zRGlNED0AAAA:8 a=dT19lrtdAAAA:8 a=qch7TRTmv8j5kB_lRzwA:9 a=CjuIK1q_8ugA:10 a=Hbpc8ax9VmIgqBixU/K2CA==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 76.187.139.93 Received: from [76.187.139.93] ([76.187.139.93:60918] helo=[192.168.0.2]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 4F/F4-21884-D3A29E25; Wed, 29 Jan 2014 16:20:17 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: More trapframe panics From: Stacey Son In-Reply-To: <52E781C6.2050308@rewt.org.uk> Date: Wed, 29 Jan 2014 10:20:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52E42A1B.3040907@rewt.org.uk> <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> <52E67F45.20402@rewt.org.uk> <2912AEFA-AA0C-456A-A814-363478BFC900@bsdimp.com> <52E781C6.2050308@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1510) 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: Wed, 29 Jan 2014 16:21:26 -0000 On Jan 28, 2014, at 4:09 AM, Joe Holden wrote: > On 27/01/2014 17:03, Adrian Chadd wrote: >> Hi joe, >>=20 >> Can you post the backtrace? And resolve the symbol names for each of >> the stackframes that show up? >>=20 >> It could be that there's some code doing dumb crap with stack frames >> that we can fix in the source. >>=20 >>=20 >>=20 >> -a >>=20 > I'll try, wondering if this box also has ram problems as even though I = regularly see page fault kernel messages on these, they don't usually = lead to a userland crash. Always helpful when fsck leaves the = filesystem in a worse state than it started because it crashed :D >=20 > Will get debug kernel built and try and tickle it again, perl built = fine in the end but libgcrypt upset it... is it worth applying those = patches from CheriBSD? Sorry, I'm little late to this thread. The CheriBSD patch that Brooks posted links to increases the kernel = thread stack size from 8K to 16K (minus sizeof(struct pcb) ) at the = expense of wiring another TLB entry. In the case of CheriBSD the pcb is = larger (see = http://fxr.watson.org/fxr/source/mips/include/pcb.h?v=3Dcheribsd;im=3Dexce= rpts#L72). This may be useful for other mips64 hardware, I don't know. = The tradeoff, of course, is one less TLB entry and, therefore, more TLB = pressure. The larger term solution might be to increase the page size = to 16K (by changing the PageMask) and use just one wired TLB entry for = the kstack pages. This will use a bit more memory for the kstacks (each = kstack will be 32K), however. The short answer is if you are using mips64 hardware and running out of = kstack space then give the changes a try. Best Regards, -stacey.= From owner-freebsd-mips@FreeBSD.ORG Wed Jan 29 22:29:14 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C43CCB2; Wed, 29 Jan 2014 22:29:14 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41D541D4D; Wed, 29 Jan 2014 22:29:14 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so3364691qae.13 for ; Wed, 29 Jan 2014 14:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lliAsYn7BjnmF/9U4LjQ+gZG2NKZw4Uj5b9+KDisj4A=; b=jVXYDvWp7Nr5Mub8zRiBCDf1MtkGPS5T3PywqBVlT68BYOdLjobesbdzc6LIHaxqZz RADPLg8RdEzLssDU/LmuEDUddXS4eJz59yADDLiaf254pz3GBvnNRfJhZXcjfQKjNn6Y nphQvHMUE03RVG3mYiqMQYEYyhuvOqJHJ8uMHROOP4CGjV2Jv5gN1uCEj9ptm8TN7prH QHjY2LNgW7SwybF7a/mgipU3CYJBoEWhwH02qFIsrxE8KrGhCmTmGgVfzGpkqdVzbZoA XjvJ8K3EYlptkPyGmEugXmxwjUvIHAf0wiz5ARzDKL5oQEsI+dM1TO0EATrAK3/PT4/R q3wQ== MIME-Version: 1.0 X-Received: by 10.224.16.72 with SMTP id n8mr16705594qaa.76.1391034553279; Wed, 29 Jan 2014 14:29:13 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Wed, 29 Jan 2014 14:29:13 -0800 (PST) In-Reply-To: References: <52E42A1B.3040907@rewt.org.uk> <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> <52E67F45.20402@rewt.org.uk> <2912AEFA-AA0C-456A-A814-363478BFC900@bsdimp.com> <52E781C6.2050308@rewt.org.uk> Date: Wed, 29 Jan 2014 14:29:13 -0800 X-Google-Sender-Auth: L8_yJsotUIPS_r457ZaAXSZwJOg Message-ID: Subject: Re: More trapframe panics From: Adrian Chadd To: Stacey Son Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 29 Jan 2014 22:29:14 -0000 isn't there a way to probe the valid pagemask values? I thought I read some way of writing in pagemask values into a fixed TLB entry and then reading them back to see which bit(s) are set and cleared. That way we could maybe do the above at boot-time with minimal evilness. -a From owner-freebsd-mips@FreeBSD.ORG Thu Jan 30 03:51:57 2014 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D721DA6D; Thu, 30 Jan 2014 03:51:57 +0000 (UTC) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by mx1.freebsd.org (Postfix) with ESMTP id 70BCA1D82; Thu, 30 Jan 2014 03:51:57 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=H69ZMpki c=1 sm=0 a=Hbpc8ax9VmIgqBixU/K2CA==:17 a=dBRESv0yCI8A:10 a=ozSPa0bqj5AA:10 a=8nJEP1OIZ-IA:10 a=6I5d2MoRAAAA:8 a=KGjhK52YXX0A:10 a=vpU8xItVDkoA:10 a=E31hHOKmAAAA:8 a=I8Tm2jY7AAAA:8 a=3F8ov1ys2yz_GBS30kIA:9 a=wPNLvfGTeEIA:10 a=SV7veod9ZcQA:10 a=vXOQVunnJF4A:10 a=Hbpc8ax9VmIgqBixU/K2CA==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 76.187.139.93 Received: from [76.187.139.93] ([76.187.139.93:50474] helo=[192.168.0.2]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id AA/B1-11872-B5CC9E25; Thu, 30 Jan 2014 03:51:55 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: More trapframe panics From: Stacey Son In-Reply-To: Date: Wed, 29 Jan 2014 21:51:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52E42A1B.3040907@rewt.org.uk> <6354182D-B1D3-4B2E-BEEC-37A2A725A099@bsdimp.com> <52E67F45.20402@rewt.org.uk> <2912AEFA-AA0C-456A-A814-363478BFC900@bsdimp.com> <52E781C6.2050308@rewt.org.uk> To: Adrian Chadd X-Mailer: Apple Mail (2.1510) 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: Thu, 30 Jan 2014 03:51:57 -0000 On Jan 29, 2014, at 4:29 PM, Adrian Chadd wrote: > isn't there a way to probe the valid pagemask values? >=20 > I thought I read some way of writing in pagemask values into a fixed > TLB entry and then reading them back to see which bit(s) are set and > cleared. >=20 > That way we could maybe do the above at boot-time with minimal = evilness. Yes, see page 107 of http://www.t-es-t.hu/download/mips/md00090c.pdf "Software may determine which page sizes are supported by writing all = ones to the PageMask register, then reading the value back. If a pair of = bits reads back as ones, the processor implements that page size. The = operation of the pro- cessor is UNDEFINED if software loads the Mask = field with a value other than one of those listed in Table 9.16, even if = the hardware returns a different value on read. Hardware may depend on = this requirement in implementing hard- ware structures" -stacey.=