Date: Fri, 03 Dec 2004 15:34:10 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: julian@elischer.org Cc: freebsd-usb@freebsd.org Subject: Re: Question about pipes and ugen Message-ID: <20041203.153410.130545387.imp@bsdimp.com> In-Reply-To: <41B0E6AE.4030207@elischer.org> References: <41B0DD18.9080300@elischer.org> <20041203.144432.89673091.imp@bsdimp.com> <41B0E6AE.4030207@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <41B0E6AE.4030207@elischer.org>
Julian Elischer <julian@elischer.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041203.153410.130545387.imp>