Clearing stalls: usbd_xfer_set_stall vs usbd_do_clear_stall_callback

[Trevor Blackwell]

I decided to handle it at user level, so I added a sysctl to count stall or
timeout errors during a clear-stall transaction. When that counter goes up
by >= 5 counts in 5 seconds, the user-level daemon does a clear-TT
transaction against the hub (using libusb20). If that doesn't solve it, it
closes all USB devices and resets the hub.

On Fri, May 20, 2011 at 4:44 AM, Hans Petter Selasky <hselasky at c2i.net>wrote:

> 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
>



-- 
Trevor Blackwell    trevor at anybots.com    650 776 7870