From owner-freebsd-usb@FreeBSD.ORG Fri Dec 3 22:34:16 2004 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A52E216A4CE for ; Fri, 3 Dec 2004 22:34:16 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DD4043D58 for ; Fri, 3 Dec 2004 22:34:16 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id iB3MX1rD009043; Fri, 3 Dec 2004 15:33:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 03 Dec 2004 15:34:10 -0700 (MST) Message-Id: <20041203.153410.130545387.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: <41B0E6AE.4030207@elischer.org> References: <41B0DD18.9080300@elischer.org> <20041203.144432.89673091.imp@bsdimp.com> <41B0E6AE.4030207@elischer.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-usb@freebsd.org Subject: Re: Question about pipes and ugen X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2004 22:34:16 -0000 In message: <41B0E6AE.4030207@elischer.org> Julian Elischer writes: : on our usb-scope the first commands on open are : : : bmRequestrType (setup packet to EP0) 80 06 01 03 00 00 00 02 00 : followed by an IN from EP0 to retrieve a descriptor string. : the IN never completes.. That's like the device that I've noticed the problem on. I usually see a ClearFeature(Halt) go to the device before the first request to an endpoint after a pipe has been opened with ugen. Are you not seeing that? : so the full picture is: : : OUT to EP2 (1 byte command requesting status to be fetched from EP3) : program exits due to some unspecified reason.. so IN on EP3 is never done.. : [device apparently times out somehow and sets HALT feature "HALT" on EP3] The device that I have doesn't set the HALT feature. I see on my scope: ClearFeature(Halt, EP1) Send Packet to EP1 ClearFeature(HALT, EP2) IN transaction from EP2 The IN transaction doesn't finish the second time. If the read is retried, the kernel will send another ClearFeature(HALT,EP2), and the device will timeout again. If another packet is sent to EP1, I get the same error. But on the third time, it succeeds. : re-run program. : opens ugen0.0 : results in: : bmRequestrType (setup packet to EP0) 80 06 01 03 00 00 00 02 00 : IN [never completes] (receives millions of NACKs from the : device). Is this the ClearFeature(Halt) packet to endpoint 1? I'm guessing not, but thought I'd ask. Our device at least will accept the packet, but the firmware on the device goes catatonic until we send the write command a few more times and issue the reset a few more times. : Linux apparently doesn't do the setup request on open but : instead just goes straight to allowing libusb to access the device.. older linux never sends the ClearFeature(Halt) packets on pipe open, so that matches what I'm seeing as well. : libusb does, times out and doesn the ClearFeature(Halt) : which apparently fixes everything. and then continues on its merry way. : : as ai said.. the device seems broken.. Yes. And in a different way than my device is broken :-) : you can unplug it and re-plug it and it is still in this state.. : : But it would be nice to be able to actually open the ugen device so that : we could try fix it like Linux does.. Yes, but we may still be talking past eachother a little on the problem... Warner