[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 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
USB keyboard/mouse, USB umass key and umodem. This patch, along
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
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
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
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 wouldn't be
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 to do.
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.
PS: something completely different - does crmfb work properly on your
R10k O2? And did you ever try my accelerated X hack?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----
Main Index |
Thread Index |