From owner-freebsd-mips@FreeBSD.ORG Mon Feb 15 15:51:58 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4ED01065670 for ; Mon, 15 Feb 2010 15:51:58 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pz0-f184.google.com (mail-pz0-f184.google.com [209.85.222.184]) by mx1.freebsd.org (Postfix) with ESMTP id 8A28A8FC14 for ; Mon, 15 Feb 2010 15:51:58 +0000 (UTC) Received: by pzk14 with SMTP id 14so5899128pzk.3 for ; Mon, 15 Feb 2010 07:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=StTXVexren364BJPjBaPf/KDbvsjTGqalZaig54xIrU=; b=KMGMdwguqSdAEFa/KN5BHUA53E2tNtORa0tJwZpkRaINS1nA5KLQIPDHMmGu5/Hd82 QZAt1OBHpgcg8AGw4BIfZV+jKl5B8UAMcMzLVc5UAM1MELodrJyfQasmafGJCBNW7KNC KcukQWHWybXJzp6h2AOpoaDNPjDEJMwjzl4+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=h+An6ZYrdbOr/MwIlge8cy3fVbLCKViRuCMZjgdTgaTYnfZD+MvcSt5JLViiHZ6G8H b0O+2JAriFsIydfmRauV2TWQgDo5TkG+ndnFO/f2xMT6rSxQCJkAXyPKEwyy+oIDpYob qbpaMh1MwVlMTfFsgEodpvQm3+Frn/QQPdnPA= MIME-Version: 1.0 Received: by 10.140.83.14 with SMTP id g14mr3492722rvb.30.1266249118066; Mon, 15 Feb 2010 07:51:58 -0800 (PST) In-Reply-To: <98a59be81002110915l2fa64189g28f13f8ad39c9584@mail.gmail.com> References: <5709963B-3F83-44FE-991F-A3227A2052DC@lakerest.net> <98a59be81002110655y60ab4e8cj473f4b6ecf6f5ae4@mail.gmail.com> <98a59be81002110915l2fa64189g28f13f8ad39c9584@mail.gmail.com> Date: Mon, 15 Feb 2010 21:21:58 +0530 Message-ID: <98a59be81002150751l2871e825ycbc9dda736870e4f@mail.gmail.com> From: "C. Jayachandran" To: Randall Stewart , freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: RMI status X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 15:51:58 -0000 On Thu, Feb 11, 2010 at 10:45 PM, C. Jayachandran wrote: > On Thu, Feb 11, 2010 at 9:08 PM, Randall Stewart wrote: >> Ahh.. I don't use a -jN since there is only one core >> currently... That would use more memory... maybe running >> the kernel out of memory below the magic 512Meg mark. If that >> happens things will break... >> > > I think you are right - I added the following patch (probably > whitespace damaged) to trap this case and it certainly seems to get > pages above 256M before it crashed(on XLR the default bootloader maps > physmem from 0-256M after that is IO and flash mapping). The two places where MIPS_PHYS_TO_CACHED(pa) is called where the physical address is not checked to be less than MIPS_KSEG0_LARGEST_PHYS are below: mips/mips/pmap.c:pmap_pinit | while ((ptdpg = vm_page_alloc(NULL, NUSERPGTBLS, req)) == NULL) | VM_WAIT; | | ptdpg->valid = VM_PAGE_BITS_ALL; | | pmap->pm_segtab = (pd_entry_t *) | MIPS_PHYS_TO_CACHED(VM_PAGE_TO_PHYS(ptdpg)); mips/mips/pmap.c:_pmap_allocpte | if ((m = vm_page_alloc(NULL, ptepindex, req)) == NULL) { | if (flags & M_WAITOK) { |[...deleted..] | pmap->pm_stats.resident_count++; | | ptepa = VM_PAGE_TO_PHYS(m); | pteva = MIPS_PHYS_TO_CACHED(ptepa); As I wrote earlier, I had added prints here, and we get addresses here which are outside the direct mapped area when there is memory more than 512M I cannot see how this can work, because vm_page_alloc can return pages which can be above the maximum KSEG0 address, and we will crash in this case.. I am trying to use 'vm_phys_alloc_contig' to allocated KSEG0 pages, but I'm still figuring out how to use that correctly - and what the performance penalty will be. Meanwhile, any ideas on this can be fixed (or better, an explanation why this is not an issue) will be very welcome. Also, in RMI's FreeBSD 6.4 code, we had a platform specific version of uma_small_alloc which would maintain a pool of kseg0 pages (using a kernel thread), I think something like that would be useful here to maintain a pool of kseg0 pages which can be used for page table too. Thanks, JC.