Dear all,

I wanted to write to talk about the status of our USB stack in
-current because there has been some concern expressed over the
last week about where were are at with it, and more importantly
when the bugs are going to be ironed out. In particular there has
been a call to backout it all out back to a time when it worked.

The background is that I've been porting the developments that
NetBSD has had into FreeBSD. In some cases we were two years behind
the state of the art. Today we're in a much better shape; most of
the controller code and device API is pretty much the same as
NetBSD's now, and that means that it should be relatively easy to
port the ehci USB2 controller code. A lot of the devices are now
synced too, although in general these have diverged over the period
a lot more than the controller code has.

With a prevailing wind behind us we should now have been in a much
better position than we were when I started this work at the beginning
of the year. I think that we almost are, but there are a few bugs
that at the moment are eluding me, they could be because the bug
exists in NetBSD, or because of some FreeBSDism that I've not
realised, or just because of some code that's not been ported yet.
I don't know, but I am working on it.

Here are the issues that I know about:

* There's a disconnect bug, which I've tied down to interupt pipes not
  cancelling properly when a device is unplugged. What this leads
  to is an xfer that repeats, and locks the usb subsystem. I've
  experienced it with uhub and ums, but it's possible, and probably,
  that other devices are effected to. I made some headway on this
  last night, and am in communication with the NetBSD author who's
  helping me track the problem down.

* There's an attach problem with the aue network device, and possibly
  cue and kue too. This bug appears to have been around for a while
  but has just been revealed by the recent memory manager changes.
  It caused an attach time panic due to a bad memory allocation.
  NetBSD's aue driver is different from ours and possibly doesn't
  have the same problem.

* Problems with ulpt.  These appear to be in NetBSD also.  I've got
  a usb printer (HP office jet) and so potentially have the resources
  to track the problem down, but as it's not entirely broken for all
  users, this problem is less important than the two about IMO.

If anyone has any others that they've not revealed I'd like to know

Also, if anyone particularly fancies helping out I'd be very grateful.
This is my first bout into the kernel, and although I've got all
the tools (remote debugger etc) I'm still a little slow with using
them. Mail me privately if you've got the time and energy to help

I'm prepared to back everything out if required, but my feeling is
that we're a stone's throw away from solving these problems; it's
just I'm throwing stones slower than a seasoned kernel hacker would.
It would be a shame to take such a large step backwards if it's
just a small step forwards that's required.

The last known good date was just before the uma commit, i.e.
-D20020319\ 0900. Of course there have been some kernel infrastructure
changes since then so it's not just a matter of backing out the
sys/dev/usb directory to that date. There are some changes that
need to be retained, but they should be obvious for anyone who wants to
do this locally.

I ask for your patience in getting to the bottom of these problems, and
wanted people to know that I am taking these issues serious, something
that might not be clear because I've not communicated much about it on
the lists.

The good news is that once these issues have been resolved we are
in a good position to port the drivers that NetBSD have but we've
not seen yet. There are lots, like uaudio and uvisor, that we should
take avantage of. I hope that these will follow in the not too
distant future.


p.s. I'm away for the weekend and so if you don't get a reply to any
email until the early part of next week it's not because I'm ignoring

Attachment: msg37984/pgp00000.pgp
Description: PGP signature

Reply via email to