libusb usb_interrupt_read hangs under FreeBSD

[Xiaofan Chen]

On 7/8/07, M. Warner Losh <imp at bsdimp.com> wrote:
> In message: <a276da400707071725x2b2b8ab3ife6c5459d06042bd at mail.gmail.com>
>            "Xiaofan Chen" <xiaofanc at gmail.com> writes:
> : On 7/5/07, Hans Petter Selasky <hselasky at c2i.net> wrote:
> : > > > > The chip does not handle a clear-stall request on the control pipe to
> : > > > > clear-stall on the interrupt pipe. The result is that the interrupt
> : > > > > pipe stops, or at least all buffers are cleared.
> : > > > >
> :
> : The following is part of the usb firmware from Micrcohip.
>
> I never learned the details, but a client of mine was able to get
> fixes from Microchip for their product.  The exact problem was that
> endpoint stall clearing didn't work for these devices and it was a
> firmware bug.
>

Thanks a lot for the info.

I ran the old USBCheck Version 5.10 with PICKit 2 and find out that it is
true that PICKit 2 failed to respond to a clear STALL feature request for
endpoint 0 (IN and OUT) even though it successfuly responded to the
clear STALL request for endpoint 1 (IN and OUT). So I think this is a
potential bug with the Microchip USB firmware framework.

According to a reply from Microchip Forum:
"There is a slight ambiguity in the USB spec concerning 'clear stall feature'.
Endpoint 0 canot stall a request, so a request to unstall endpoint 0 is
completely redundant. I recall that the required response is not clearly
defined. Personally, I just accept the request and acknowledge it, but there
is no real action to be taken. I guess other software writers have chosen a
different path."

Why FreeBSD sends out the clear stall feature request for PICKit 2?

Regards,
Xiaofan