From owner-freebsd-usb@FreeBSD.ORG Fri Dec 3 23:26:38 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 C126116A4CE for ; Fri, 3 Dec 2004 23:26:38 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FF3443D53 for ; Fri, 3 Dec 2004 23:26:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 496AD7A44F; Fri, 3 Dec 2004 15:26:38 -0800 (PST) Message-ID: <41B0F62E.5060502@elischer.org> Date: Fri, 03 Dec 2004 15:26:38 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: "M. Warner Losh" References: <41B0DD18.9080300@elischer.org> <20041203.144432.89673091.imp@bsdimp.com> <41B0E6AE.4030207@elischer.org> <20041203.153410.130545387.imp@bsdimp.com> In-Reply-To: <20041203.153410.130545387.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 23:26:38 -0000 M. Warner Losh wrote: >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] > > > >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. > > I take that back Here's a better description. endpoints are: 0 setup 1 control channel in 2 control channel out 3 data in the request for status is made to 2 (OUT, 1 byte) the read that never happens would be on 1 On Linux: After a large delay, we (after restarting the program) try to do the OUT to EP2 again. (this is the first USB wire transaction since restarting the program) we get 288000 NAKS (literally) before we time out. To get things going again, linux libusb sends a ClearFeature(HALT) to EP2 and then follows it with a GetStatus(EP2) to check and then retries the OUT to EP2 again, which now succeeds, On FreeBSD 4-stable, the action of openning ugen.1 results in mRequestrType (setup packet to EP0) 80 06 01 03 00 00 00 02 00 followed by an IN on EP0 which just hangs. (apparently the backing firmware is still waiting to respond to an IN on EP1.) Since the setup packet is part of the open() of ugen 0.1 and 0.0 we don't know to do a ClearFeature(HALT) to EP1 or EP2 as we never are able to get to teh point of trying the write. I will see if I need to MFC somethign in usb.c or usbdi.c or ugen.c to do the endpoint clear as needed. > >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 :-) > not working on a check scanner are you? :-) > >