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 07:11, Manuel Bouyer wrote:
On Mon, Jun 23, 2008 at 05:41:53PM -0400, Michael Lorenz wrote:

On Jun 23, 2008, at 12:20, Manuel Bouyer wrote:

attached is a patch that adds bus_dmamap_sync() calls for uhci,
ohci and ehci.
I've tested uhci and ehci on amd64 (both intel and add-on VIA ehci)
sgimips (add-on VIA ehci). ohci has been tested on amd64 and macppc
(both with the build-in USB controller). All tests have been done with
USB keyboard/mouse, USB umass key and umodem. This patch, along
with the
one in PR port-i386/38935, fix the race condition that cause
"host controller process error" and "host controller halted" errors
umodem@uhci is under heavy use.

Michael Lorenz reported issues with this on uhci/ehci in a sgimips O2,
but I couldn't reproduce it. It may be an issue with his add-on

I see the same problems with an ohci/ehci card equipped with a NEC
chip which works perfectly fine on macppc and sparc64, so I guess the
problem is sgimips-specific. Since you don't see it I better look for
local hacks in my source tree :/

Or some difference between CPUs. But from what you said, my R10000 should
cause more issues than your R5000, as your should only reorder writes
while mine can also reorder reads.

Yeah, I was surprised that it worked for you - lots of people have all kinds of weird trouble with R10k O2s.

The funny thing is that I only have problems with USB cards, an ex
and the onboard ahc's Just Work.

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 descriptors,
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 memory,
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.

have fun

PS: something completely different - does crmfb work properly on your R10k O2? And did you ever try my accelerated X hack?

Version: GnuPG v1.4.7 (Darwin)


Home | Main Index | Thread Index | Old Index