[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bus_dmamap_sync() for uhci(4)
On Mon, Jun 09, 2008 at 05:44:18PM -0400, Michael Lorenz wrote:
> >>>BTW, I suspect the lack of memory read/write barrier are the
> >>>cause of
> >>>the issues I'm seeing on x86 too (this is why I started this work).
> >>Hmm, I need to read sgimips' bus_dma stuff again but since other
> >>drivers work it can't be all that borked.
> >Sure it was not my point. It's most probably an issue with the
> >_sync() calls I added. But as the memory referred to by these calls
> >should be
> >mapped uncached anyway, I don't understand how they could make a
> Something's weird here - I added the KASSERT you asked for, didn't
> add ehci back but the kernel found the USB disk this time. It did
> hang while probing a low speed device though ( sat there for a minute
> or so ), when I unplugged it the machine booted normally and so far
> bonnie's been working for about 10 minutes without any trouble. For
> some reason it took a lot longer than on my other machines to find
> the USB disk ( ~15 seconds vs. less than one )
So the KASSERT didn't fire, which means that the memory here is mapped
uncached. In this case, the bus_dmamap_sync() should just add a wmb() in
the path, which should make things really worse (it's _bus_dmamap_sync_mips3()
which is used on the O2, right ?).
when using BUS_DMAMAP_COHERENT, is the memory region completely uncached
on sgimips, or do we still need to invalidate the cache line before a
Manuel Bouyer, LIP6, Universite Paris VI.
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |