From owner-freebsd-arm@FreeBSD.ORG Wed Jan 7 22:24:10 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 74B8A1065C87 for ; Wed, 7 Jan 2009 22:24:10 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 1B36D8FC18 for ; Wed, 7 Jan 2009 22:24:10 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id B1D488FC51 for ; Thu, 8 Jan 2009 01:24:08 +0300 (MSK) Received: from orion.SpringDaemons.com (drsun1.dialup.corbina.ru [85.21.245.235]) by mx0.deglitch.com (Postfix) with ESMTPA id D98508FC18; Thu, 8 Jan 2009 01:24:05 +0300 (MSK) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id BEF29398F3; Thu, 8 Jan 2009 01:26:33 +0300 (MSK) Date: Thu, 8 Jan 2009 01:26:27 +0300 From: Stanislav Sedov To: Mark Tinguely Message-Id: <20090108012627.4ed3e907.stas@FreeBSD.org> In-Reply-To: <200901072153.n07LrNZU063946@casselton.net> References: <20090107223428.93bf0942.stas@FreeBSD.org> <200901072153.n07LrNZU063946@casselton.net> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Thu Jan 8 01:24:08 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 49652b88967002281716519 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 22:24:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 7 Jan 2009 15:53:23 -0600 (CST) Mark Tinguely mentioned: > 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. It looks like I've found the place where the mapping could not be invalidated because of this. In ohci2.c we need the ed descriptor to be synchronized before we access it, but busdma fails to sync it. I tried to do what busdma does by hand, but this doesn't make "ed" to be consistent as well: cpu_idcache_wbinv_range((vm_offset_t)ed->page_cache->map->buffer, ed->page_cache->map->len); After calling cpu_idcache_wbinv_all at this point (which invalidates and cleans all entries) ed contains correct entries. Thus it seems that because of double mappings cpu_idcache_wbinv_range fails to clean the entry (it seem to clear the old one instead). I'll think about your points here, need to study pmap and busdma code a bit first. Thanks for clearing this out! - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkllLBkACgkQK/VZk+smlYERswCggfXhIHlTAZZ0nymRwwRPQKwf NaQAn2tHgT4ez2eHfRyC/JMX37eKiuLU =jzsU -----END PGP SIGNATURE----- !DSPAM:49652b88967002281716519!