From owner-freebsd-mips@FreeBSD.ORG Fri Sep 10 07:00:36 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 F1AE0106564A; Fri, 10 Sep 2010 07:00:36 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 823298FC13; Fri, 10 Sep 2010 07:00:36 +0000 (UTC) Received: by ywt2 with SMTP id 2so1143257ywt.13 for ; Fri, 10 Sep 2010 00:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=haS4zf0ETKXjhgVIUHJO4kqT+bRpCrtH8jDT8kbbtfQ=; b=fbBMuXTluAEEU8wnd3aEZ70jW5+ea+w5swDAI8mSWRE80D7F3/Nd+0CZYtnPik8CVd rBisFa8QJM2W2bMJH6wS+uOBJRTfwbebJ7WtYJF6rRYe2s8EE7w1Od4gpCqNW63//c/v bKV1zZ6DouOnaFxUFXexnSPIhF2GkWsQcBFuE= 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 :cc:content-type:content-transfer-encoding; b=VuGqDtrztM5YiZQCtdjONb7ksZzr13ZxLhzY9qhM630gTP1y9WvnoR5nYjwIRa0Px3 sAH40y6BsmBUISQCC9YptdOr+NNaSOJMzJVcqUG194Rdlw/KWqRjy8QwZfZXNgPO2Eml FHwkbHL5afO1hHRmx5DjpF6fcYDIe3xnca+DQ= MIME-Version: 1.0 Received: by 10.150.11.21 with SMTP id 21mr400674ybk.39.1284102035429; Fri, 10 Sep 2010 00:00:35 -0700 (PDT) Received: by 10.150.136.10 with HTTP; Fri, 10 Sep 2010 00:00:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Sep 2010 12:30:35 +0530 Message-ID: From: "Jayachandran C." To: Neel Natu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: gonzo@freebsd.org, freebsd-mips@freebsd.org Subject: Re: busdma_machdep.c with more than 512M memory 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: Fri, 10 Sep 2010 07:00:37 -0000 On Fri, Sep 10, 2010 at 11:22 AM, Neel Natu wrote: > Hi JC, > > On Mon, Sep 6, 2010 at 12:38 AM, Jayachandran C. > wrote: >> On Mon, Sep 6, 2010 at 1:04 PM, Jayachandran C. >> wrote: >>> On Wed, Sep 1, 2010 at 12:37 PM, Jayachandran C. >>> wrote: >>>> I was looking at a few crashes I see with PCI drivers, and I think it >>>> is caused by an issue in busdma_machdep.c where physical address is >>>> directly converted using MIPS_PHYS_TO_KSEG1. I have not looked at it >>>> in detail, but it looks obviously wrong. >>>> >>>> Any suggestions on how to fix thiis is welcome, it probably needs an >>>> uncached TLB entry. On 64bit we could use XKPHYS uncached. >>>> >>>> >>>> --- >>>> =A0632 =A0 =A0 =A0 =A0 if (newmap->flags & DMAMAP_UNCACHEABLE) { >>>> =A0633 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 void *tmpaddr =3D (void *)*vadd= r; >>>> =A0634 >>>> =A0635 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (tmpaddr) { >>>> =A0636 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tmpaddr =3D (vo= id >>>> *)MIPS_PHYS_TO_KSEG1(vtophys(tmpaddr)); >>>> =A0637 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 newmap->origbuf= fer =3D *vaddr; >>>> =A0638 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 newmap->allocbu= ffer =3D tmpaddr; >>>> =A0639 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mips_dcache_wbi= nv_range((vm_offset_t)*vaddr, >>>> =A0640 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dmat->m= axsize); >>>> =A0641 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *vaddr =3D tmpa= ddr; >>>> =A0642 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } >>>> --- >>>> 1361 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bpage->busaddr =3D pmap_kextract(= bpage->vaddr); >>>> 1362 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bpage->vaddr_nocache =3D >>>> 1363 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (vm_offset_t)MIPS_PHYS_TO= _KSEG1(bpage->busaddr); >>>> 1364 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mtx_lock(&bounce_lock); >>> >>> Based on Juli's suggestion, I have a patch (attached) to switch the >>> calls to pmap_mapdev/pmap_unmapdev. >>> >>> Seems to work for me now, please review. >> >> That was an older version of the patch, here is the correct version. >> > > This assumes that pmap_mapdev() always returns an uncached mapping > which is true for n64 kernels but not for o32 kernels with memory > beyond 512MB. I think my original patch was incorrect, pmap_mapdev() should not be used to map physical memory uncached. It may be just for mapping device address space uncached, and that may be why it checks if the physical address is cacheable. > Any objections if I commit the following patch that makes > pmap_mapdev() always return an uncached mapping. I think we should remove the usage of pmap_mapdev() in busdma and just use your new pmap_kenter_attr() there, which I think would make it clear. Thanks, JC.