Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Jan 2009 15:53:23 -0600 (CST)
From:      Mark Tinguely <tinguely@casselton.net>
To:        stas@FreeBSD.org, 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:  <200901072153.n07LrNZU063946@casselton.net>
In-Reply-To: <20090107223428.93bf0942.stas@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
>  On Wed, 7 Jan 2009 12:46:14 -0600 (CST)
>  Mark Tinguely <tinguely@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?
>
>  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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901072153.n07LrNZU063946>