From owner-freebsd-usb@FreeBSD.ORG Thu May 5 21:51:22 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 EE5611065672 for ; Thu, 5 May 2011 21:51:22 +0000 (UTC) (envelope-from trevor.l.blackwell@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A35BA8FC0C for ; Thu, 5 May 2011 21:51:22 +0000 (UTC) Received: by ywf7 with SMTP id 7so1202954ywf.13 for ; Thu, 05 May 2011 14:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=AFvSnoPHPpg2pj0i+sctlK6XT2K4xTCm22M+pnnGKSM=; b=QXFKAoxTjMK+PFhkNTpkRi2laAgIfT0ysL0lMTtRkrDM6+7/xmw3kXYkeiNXwaITKT ddFsp3dwKvl1mXn/Esa6bu2f23Mb9TEPBO15cPkFBV+D5jtjMAfGQZmyl61xac7yNTXU b+EFn/4ghRMbpOfJrCdMszZaYAuhkFyS5O4Ng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=pWXf5RLqNeyHxCsAA+dhRJacBlKEAwWL4EJq9PVMM+86dHSt2TiW7M8EuMNnBX7FPG uRxm5Ybu5eTiCOsSkOMcCaee6mUVbZa4Q7lThoF0KdAhBXpCk4Y0cEN6oGhmkr0ZF2Ui I6TBEn+3EGq9fmR0w1djEOiX8V7w1hN5gBmgo= MIME-Version: 1.0 Received: by 10.236.136.37 with SMTP id v25mr3771552yhi.341.1304632281754; Thu, 05 May 2011 14:51:21 -0700 (PDT) Sender: trevor.l.blackwell@gmail.com Received: by 10.236.103.2 with HTTP; Thu, 5 May 2011 14:51:21 -0700 (PDT) In-Reply-To: <201105051009.55454.hselasky@c2i.net> References: <201105050841.56095.hselasky@c2i.net> <201105051009.55454.hselasky@c2i.net> Date: Thu, 5 May 2011 14:51:21 -0700 X-Google-Sender-Auth: CBrFKcnEYsX8h3nspORs2fvW-tY Message-ID: From: Trevor Blackwell To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: Thu, 05 May 2011 21:51:23 -0000 > 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 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