tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bus_dmamap_sync() for USB

Hash: SHA1


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
much more
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
controller don't
write list pointers to main memory, or read list pointers from main
in a very specific order, the list can become corrupted. I wouldn't be
surprised if there were some silicon bugs in this area, which would
show up
only in some timing conditions. What makes things worse, and
different from
an ethernet or disk controllers, is that the USB controller scan
the descriptor lists every microsecond, even if there's nothing to do.
ethernet (at last the ex) or disk controllers will do DMA only when
they know
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
race condition(s).
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 had
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 mapping, so no read/write reordering should happens here (this is what I've been 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 barriers.

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.

Thanks :)

have fun

Version: GnuPG v1.4.7 (Darwin)


Home | Main Index | Thread Index | Old Index