From owner-freebsd-arm@FreeBSD.ORG Wed Jan 7 21:53:27 2009 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56BB51065A93; Wed, 7 Jan 2009 21:53:27 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id D409B8FC2E; Wed, 7 Jan 2009 21:53:26 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id n07LrNi6063947; Wed, 7 Jan 2009 15:53:23 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1231365204; bh=4qo/87vFqSreuNfqFKkxkQC3FnWhLtKGFnSknLA aG6k=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=lnSIfk4K 0M9mfkDV2MA79FZb3vQX95Z0srDTvtKw+Qk/aZOtmxEzoLR1hescSMH83yZGap6Ngi8 +kMcaDG700IDCT8JKFtOdXgk/eVHqUqlSQffgU6g3Cm3pZtZaHFVJUktgCquJSPI71s jKrgBv6wGH7QqhKE0LQnthNTHuytQ= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id n07LrNZU063946; Wed, 7 Jan 2009 15:53:23 -0600 (CST) (envelope-from tinguely) Date: Wed, 7 Jan 2009 15:53:23 -0600 (CST) From: Mark Tinguely Message-Id: <200901072153.n07LrNZU063946@casselton.net> To: stas@FreeBSD.org, tinguely@casselton.net In-Reply-To: <20090107223428.93bf0942.stas@FreeBSD.org> Cc: arm@FreeBSD.org, alfred@FreeBSD.org Subject: Re: svn commit: r186730 - in head: lib/libusb20 sys/dev/usb2/controller sys/dev/usb2/core sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2009 21:53:29 -0000 > On Wed, 7 Jan 2009 12:46:14 -0600 (CST) > Mark Tinguely mentioned: > > > It could be the same problem if there is a duplicate kernel mapping. If > > there is no duplicate kernel mapping, then there is another cache leak > > somewhere. > > > > Yeah, it seems it leaks somewhere as invalidating the entire wb cache > in case of coherent mapping in sys/arm/arm/busdma_machdep.c:_bus_dmamap_sync, > where currently it simply returns solves the problem. In fact, all usb memory > is mapped as coherent and thus should not require cache flush, but something > goes wrong. Could additional entries established by arm_remap_nocache in > case of coherent mapping interfere with previous mappings and thus create > problems? Is it the same case as duplicate mappings? > > Thanks! > - -- > Stanislav Sedov > ST4096-RIPE Coherent in ARM is a duplicate mapping with a special VA above the KVM. The new kernel entry is mapped with cache turned off (pmap_kenter_nocache()), but the original virtual mapping still has caching turned on. In fact, pmap_kenter_nocache() invalidates/writebacks the new special VA, but does not writeback/invalidate the original virtual mapping - that is where your problem originates and why your writeback/invalidates works. If you trust that the other mapping will not modify memory - which in this case, I believe we can - a quick solution would be to add a writeback/invalidate (pmap_fix_cache) in the second for loop of arm_remap_nocache(). But I would have to make sure the pmap_fix_cache counts the new un-managed kernel mapping before I recommend that. When I wrote the patch, I grepped for pmap_kenter_* routines, and noticed as side effect of managing the cohert code is also fixed and in fact it can be simplified greatly. At the time - before the usb2 import, I grepping the sources and there were only a couple network adapters using BUS_DMA_COHERENT, so I was not too concerned. --Mark Tinguely.