From owner-freebsd-usb@FreeBSD.ORG Fri May 20 11:45:47 2011 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D4F9106564A for ; Fri, 20 May 2011 11:45:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 15E948FC19 for ; Fri, 20 May 2011 11:45:46 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=1W/zHQV/91afZrGZjnmxK4mmm0xPtKVmshL3njyU5IE= c=1 sm=1 a=SvYTsOw2Z4kA:10 a=Qcgr9xoES4kA:10 a=WQU8e4WWZSUA:10 a=Q9fys5e9bTEA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=m0bHr2FCAAAA:8 a=MXBzv6Jk0HeXkwUKECsA:9 a=PUjeQqilurYA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mailfe01.swip.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-TFF-CGPSA-Version: 1.7 X-T2-CGPSA-Filter: Scanned Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 129817826; Fri, 20 May 2011 13:45:43 +0200 From: Hans Petter Selasky To: Trevor Blackwell Date: Fri, 20 May 2011 13:44:35 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: <201105051009.55454.hselasky@c2i.net> In-Reply-To: <201105051009.55454.hselasky@c2i.net> X-Face: *nPdTl_}RuAI6^PVpA02T?$%Xa^>@hE0uyUIoiha$pC:9TVgl.Oq, NwSZ4V"|LR.+tj}g5 %V,x^qOs~mnU3]Gn; cQLv&.N>TrxmSFf+p6(30a/{)KUU!s}w\IhQBj}[g}bj0I3^glmC( :AuzV9:.hESm-x4h240C`9=w MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201105201344.35918.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: Clearing stalls: usbd_xfer_set_stall vs usbd_do_clear_stall_callback X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 11:45:47 -0000 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