svn commit: r186730 - in head: lib/libusb20
sys/dev/usb2/ethernet sys/dev/usb2/image sys/dev/usb2/include
sys/dev/usb2/serial sys/dev/usb2/sound sys/dev/us...
tinguely at casselton.net
Wed Jan 7 13:53:29 PST 2009
> On Wed, 7 Jan 2009 12:46:14 -0600 (CST)
> Mark Tinguely <tinguely at casselton.net> 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?
> - --
> Stanislav Sedov
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.
More information about the freebsd-arm