Re: bus_dmamap_sync() for USB

[Michael Lorenz <macallan%netbsd.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

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)
> > > and
> > > 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
> > > when
> > > 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
> > > adapter.
> >
> > 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
Michael

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)

iQEVAwUBSGDtZcpnzkX8Yg2nAQIz8gf/ePubyL1WiZTkef82L1No8yCyWHXI7jPF
QHjinxkphkteIKJjWoMNrSHnXV678iBvwLKL5PXWsyIK0qDnlV2bzIXw2zhP/5oh
nVM16OJbjxsWW94OXSjIT5/BEvLus8u6cdiTM9uYrpjQn54jybn32kg3ky593Hh4
GqljP29INKDNQz4RMarJfOCb9Pf2qoIuFKW34xScTj4m8cSOZ2hibEctHifQxKEf
KvfCw9GOPBCLAomumISntHByjFu4NfkGEWD2xeSzvv9XMIhlnh+fXAV8c2o/T+Td
o0Be0lden+Nzh2Cqdm1PMn2qHFpWuqcLwU8stgJwm+FzxQg84mNjaw==
=eOTz
-----END PGP SIGNATURE-----