On Thursday 05 May 2011 10:09:55 Hans Petter Selasky 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 > > > > (UT_WRITE_CLASS_OTHER, UR_RESET_TT) > > > > 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. > > Could a control endpoint timeout in general imply that the parent High > Speed HUB, if any, should be reset? > > --HPS
Any updates on this issue? --HPS _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"