Date: Thu, 8 Jan 2009 01:26:27 +0300 From: Stanislav Sedov <stas@FreeBSD.org> To: Mark Tinguely <tinguely@casselton.net> 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... Message-ID: <20090108012627.4ed3e907.stas@FreeBSD.org> In-Reply-To: <200901072153.n07LrNZU063946@casselton.net> References: <20090107223428.93bf0942.stas@FreeBSD.org> <200901072153.n07LrNZU063946@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 7 Jan 2009 15:53:23 -0600 (CST)
Mark Tinguely <tinguely@casselton.net> 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090108012627.4ed3e907.stas>