Date: Wed, 08 Jul 2009 08:23:43 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: hselasky@c2i.net Cc: freebsd-usb@freebsd.org, raj@semihalf.com, freebsd-arm@freebsd.org, thompsa@freebsd.org Subject: Re: CPU Cache and busdma usage in USB Message-ID: <20090708.082343.-1343671115.imp@bsdimp.com> In-Reply-To: <200907081103.45388.hselasky@c2i.net> References: <200907071846.42086.hselasky@c2i.net> <37C51279-42D8-49DE-8249-0DA386EBB062@semihalf.com> <200907081103.45388.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200907081103.45388.hselasky@c2i.net>
Hans Petter Selasky <hselasky@c2i.net> writes:
: On Wednesday 08 July 2009 10:58:17 Rafal Jaworowski wrote:
: > On 2009-07-07, at 18:46, Hans Petter Selasky wrote:
: > >> I had Checked USB behaviour on PowerPC without hardware cache
: > >> coherency.
: > >> The problem also exists here and patch helps.
: > >
: > > In my source code view the busdma sync function is empty for power-
: > > pc. Your
: > > patch should have no effect at all for sync operations?
: >
: > This was about the PPC4xx PowerPC port, not committed to the tree yet.
: > Unlike most PowerPC this system has a de-coherent DMA and therefore
: > its busdma sync is non empty, but needs to enforce coherency by
: > software.
: >
: > The point is this is another platform on which USB stack (usb_pc_cpu_*
: > functions) shows similar issues as reported for ARM and MIPS.
:
: And what about my patch suggestion in my previous e-mail having the same
: subject. Does it work?
:
: Regarding my testing on the AT91RM9200 I was short of time yesterday and will
: try to get it done today.
I think that the root cause of this issue is two fold.
First, The 4 operations for busdma are being collapsed to only 2
operations. There are four for a reason (since you have to do
different things for each case).
Second, and I think this is more important, I think that we're seeing
some cache-line poisoning. We're flushing the entire busdma tag
rather than just one cache line since we don't have the API to do
that. In addition, I don't think that the USB code is being careful
enough to ensure that we don't have buffers that live in the same
cache line that are simultaneously being used for read and write. The
corruption we're seeing is a classic signal that this may be going on,
although I must admit that I've not done the detailed analysis to
prove it.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090708.082343.-1343671115.imp>