OHCI isoc problem identified, sort of, and uaudio

[Barry Bouwsma]

Sheesh, I hate binary searches, when it takes 15 minutes to decide
if a problem is or isn't present...

I'm happy to report that I think I've found two solutions to my isoc
TD alloc OHCI problem I mentioned a bit earlier.

First of all, taking the latest ohci.c from NetBSD-current and
plugging it into my FreeBSD-4 source, with a few changes to get it
to compile, plays back through my sound card for much longer than
any FreeBSD ohci.c that I tried.  Even though I merged in most all
the deltas I saw between
 *      $NetBSD: ohci.c,v 1.146 2003/12/29 08:17:10 toshii Exp $
listed in
__FBSDID("$FreeBSD: src/sys/dev/usb/ohci.c,v 1.39.2.13 2004/11/24 19:04:30 julian Exp $");
and the NetBSD-current 1.152 ...

Still, there are a boatload of differences between my latest pre-4.11
ohci.c and NetBSD-current ohci.c.  I don't know how many of them are
important to have.  I couldn't see any problems between the two,
apart from the isoc TD alloc problem being absent with NetBSD, after
more than 25 minutes playback (well over 2x as long as the longest
I could ever play with the 4.x FreeBSD ohci.c)...  I suspect that
scrapping the FreeBSD4 ohci.c in favour of NetBSD's is not a serious
option for anyone else.  So...

Through an imprecise process of elimination, it looks as though
only the following two highlighed lines are needed to be added to
my 4.x ohci.c (includes most deltas from NetBSD 1.146-1.152, and
Ian Dowse's usb_race.diff and usb2_sync.diff, as well as the patch
mentioned by someone else in the ueagle tarball, but not usb.diff).
Here's an ugly diff, in ohci_softintr() :


--- ohci.c-race+sync+ueagle	Sat Dec  4 13:48:28 2004
+++ ohci.c	Sun Dec  5 10:41:44 2004
@@ -1527,11 +1615,26 @@
 						    OHCI_CC_NOT_ACCESSED) ? 0 :
 						    OHCI_ITD_PSW_LENGTH(len);
 						xfer->frlengths[i] = len;
+#if 0 /* XXX HACK this is missing from latest NetBSD */
+						actlen += len;
+#endif /* XXX HACK this is missing from latest NetBSD */
 					}
 				}
 				if (sitd->flags & OHCI_CALL_DONE)
 					break;
+#if 1 /* XXX HACK this is missing from latest NetBSD */ /* XXX PROBS ???  Ok as 1, hangs as 0? */
+				ohci_free_sitd(sc, sitd);
  =====>>>                      ^^^^^^^^^^^^^^^^^^^^^^^^^
+#endif /* XXX HACK this is missing from latest NetBSD */
 			}
+#if 1 /* XXX HACK this is missing from latest NetBSD */ /* XXX PROBS ???  Ok as 1, hangs as 0? */
+			ohci_free_sitd(sc, sitd);
  =====>>>              ^^^^^^^^^^^^^^^^^^^^^^^^^
+#if 0 /* XXX HACK to see if this all is needed */
+			if (uedir == UE_DIR_IN &&
+			    xfer->status == USBD_NORMAL_COMPLETION)
+				xfer->actlen = actlen;
+			xfer->hcpriv = NULL;
+#endif /* XXXX HACK to see if this all is needed */
+#endif /* XXX HACK this is missing from latest NetBSD */
 
 			s = splusb();
 			usb_transfer_complete(xfer);


Everything else present in NetBSD-current but not in FBSD4.x
I'm able to wrap with #if 0 as seen above; likewise, everything
present in FBSD4.x but missing in NetBSD-current does not seem
to give problems when wrapped with #if 1.

I haven't tested beyond playing for about 20 minutes.  That
will be my next test.  Running as I write this.

Someone familiar with the ohci.c code (or USB) may want to
eyeball the above, as well as all the differences between the
latest NetBSD code and FreeBSD-4's.  That wouldn't be me, as
I have no clue about what's in the code and what it's doing,
and I have no idea what I'm doing.

I don't know if this problem affects FreeBSD-current or 5.x,
but it should be easy enough to figure out by playing through
uaudio.


More observations about uaudio:
NetBSD does not experience the short repeated beginning of the
audio playback that I hear with FreeBSD.  As noted, I'd be
inclined to blame the FreeBSD audio stack for this.  Apart
from this, playback through both is nice and clean.

NetBSD has no problems playing through my ``sound card'' uaudio
device at other than 48000Hz sample rate.  I haven't looked at
the uaudio code at all.


The remaining OHCI issue I have, is that on powerup of external
hubs, three of my four external hubs trigger the overcurrent
register which disables that port.  I think this is also a
problem with NetBSD, although there was work done in that area
a while ago.  These hubs have no problems with UHCI (my card
powers them on when my machine goes on; this OHCI card waits
until probe time to apply power), and a while back, I was able
to successfully apply power by somehow looping around during
the power-on part of code.  This needs more study to help me
retire my wall warts.

I need to do more with UHCI, to see if I can boot reliably on
this machine without a random one of the two controllers going
south soon after boot -- like to see if NetBSD has this problem
as well on this hardware, as my other machine didn't experience
this problem with the same card.

Plus the UHCI-if_axe plug-in interactions, plus the EHCI-if_axe
oddities.  When I sent out my last mail with EHCI+axe, the DNS
queries from the different recipients to my nameserver caused
`resource unavailable' messages to be logged, which usually is
not a problem with other lists and far more subscribers (except
when I was connected via slow dial-in) -- so something is less
than optimal.  Plus test if EHCI without usb.diff is better for
me now than when I experienced problems months ago.


hope this is somehow useful...
barry bouwsma