> Could a control endpoint timeout in general imply that the parent High
> Speed HUB, if any, should be reset?

Yes, I think so. Sadly, there's no way to query whether a TT is jammed or
not. So my heuristic is that when a clear-stall transaction fails with a
timeout, and it's to a full-speed device with a high-speed hub, to reset the
TT. Resetting the TT will cause every other device using it to require
require a clear-stall sequence, but that's not a big problem.

We see hub wedging problems multiple times per hour. because this system has
a long cable from the host to hub, and there are frequent static discharges
nearby. I've been testing with a static discharge simulator that hits the
cables with nanosecond kilovolt pulses and it's made it much easier to
reproduce the problems. So I can probably propose a set of patches in the
next week or so.

On Thu, May 5, 2011 at 1:09 AM, Hans Petter Selasky <hsela...@c2i.net>wrote:

> On Thursday 05 May 2011 09:15:09 Trevor Blackwell wrote:
> > 8.2-STABLE. I'm willing to run whatever.
> >
> > I suspect the problem I'm having is the same as this:
> > http://kerneltrap.org/mailarchive/linux-usb/2009/5/15/5761363
> >
> > I can manually kick it out of the wedged state by sending a RESET_TT
> > transaction to the hub with usbconfig -d ugen1.3 do_request 0x23 0x09
> > 0x0000 0x0001 0
> >
> >
> > I'm working on adding code to do this. My current hack is to do it from
> > uhub_explore. When my driver tries to do a clear-stall and gets a timeout
> > error from the clear-stall, it sets a flag on the parent_hs_hub to
> request
> > a RESET_TT. uhub_explore notices the flag and does it.
> >
> > Possibly I could also add it to usb_do_clear_stall_callback, but I don't
> > think I can call usb_do_request from inside a callback.
> >
> > Any suggestions?
> Hi,
> I think it is best to do this from the root HUB thread, then the operation
> gets properly serialised. Then the clear-stalls requests will simply be
> pending until normal operation is established.
> --HPS

Trevor Blackwell    tre...@anybots.com    650 776 7870
freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to