[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bus_dmamap_sync() for USB
-----BEGIN PGP SIGNED MESSAGE-----
On Jun 24, 2008, at 09:24, Manuel Bouyer wrote:
On Tue, Jun 24, 2008 at 08:49:41AM -0400, Michael Lorenz wrote:
The way USB controllers (all of uhci, ohci and ehci) works makes it
sensitive to race conditions: there are linked lists of DMA
which is managed by both the host and the contrller (both can add or
remove elements from the lists). If both the host and the
write list pointers to main memory, or read list pointers from main
in a very specific order, the list can become corrupted. I
surprised if there were some silicon bugs in this area, which would
only in some timing conditions. What makes things worse, and
an ethernet or disk controllers, is that the USB controller scan
the descriptor lists every microsecond, even if there's nothing
ethernet (at last the ex) or disk controllers will do DMA only when
they have work to do.
This sounds like a good explanation of what I'm seeing.
I'll try your latest patch later today - you said you fixed another
This leaves the question why the ohci/ehci board just works in much
faster machines ( namely an 800MHz G4 and a dual 450MHz US-II ) - I'd
expect them to be more sensitive to race conditions like that. On the
other hand, they might just be fast enough for the CPU to (almost)
always win the race.
This is one explaination. Interrupt latency may also play a role; I
much more troubles under Xen than with native amd64.
Hmm, I didn't look at the crime-specific interrupt code that much but
what passes for a PIC there isn't exactly complicated - just a bunch
of bitfields, pretty much like what Apple used in old world Macs. So,
doesn't have to be overly elaborate.
AFAIK, NetBSD/sparc64 uses the full-ordered memory model for kernel
so no read/write reordering should happens here (this is what I've
told when I asked about memory barrier on sparc64). I don't know
about the G4.
All PowerPCs will re-order memory accesses in some way but I'm pretty
sure our powerpc-specific bus_space ops cheat by already containing
PS: something completely different - does crmfb work properly on your
R10k O2? And did you ever try my accelerated X hack?
I've used it though serial console for the USB tests. I can try the
VGA display this evening.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
Main Index |
Thread Index |