Date: Thu, 5 May 2011 14:51:21 -0700 From: Trevor Blackwell <trevor@anybots.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: Clearing stalls: usbd_xfer_set_stall vs usbd_do_clear_stall_callback Message-ID: <BANLkTin8CXZExgn6p20NNwoZ0fyiR%2BTXkA@mail.gmail.com> In-Reply-To: <201105051009.55454.hselasky@c2i.net> References: <BANLkTik9MDy_tS3s78xG9VtbTaW%2BnCoM9A@mail.gmail.com> <201105050841.56095.hselasky@c2i.net> <BANLkTi=8--eu8%2BxWt26eJP3P3DYQ0En%2BSg@mail.gmail.com> <201105051009.55454.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <hselasky@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 > > > > (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. > > > --HPS > -- Trevor Blackwell trevor@anybots.com 650 776 7870
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTin8CXZExgn6p20NNwoZ0fyiR%2BTXkA>