[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bus_dmamap_sync() for uhci(4)
-----BEGIN PGP SIGNED MESSAGE-----
On Jun 10, 2008, at 09:52, Manuel Bouyer wrote:
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
the issues I'm seeing on x86 too (this is why I started this
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
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
the path, which should make things really worse (it's
which is used on the O2, right ?).
Yes, if not that would be a bug.
when using BUS_DMAMAP_COHERENT, is the memory region completely
on sgimips, or do we still need to invalidate the cache line before
a read ?
Currently BUS_DMAMAP_COHERENT translates to 'access via kseg1' on
sgimips. Yes, should be completely uncached.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
Main Index |
Thread Index |