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" >