libusb usb_interrupt_read hangs under FreeBSD

[Xiaofan Chen]

On 7/15/07, Hans Petter Selasky <hselasky at c2i.net> wrote:
> >
> > 2) For the host, how does it know that the buffer data is still correct if
> > the buffer is not cleared?
>
> Clear stall should only clear the data toggle!
>
> You need a second control command to reset the buffers and/or the protocol!
>
> >
> > 2) What cause the stall to happen in the first place?
>
> It is either a wrong data-toggle bit or a protocol error. The device can send
> stall at any time!
>

Thanks a lot for the detailed explanation.

If it is a protocol error for the control endpoint 0 (EP0), the host will not
need to send a clear stall feature request to EP0. Even if it is sent
(shall we consider it a bug of the USB stack if that is the case?),
the current PICkit 2 firmware will filter out it and ignore it.

So I think we can narrow it down to the wrong data-toggle bit. I will
dig further. I'd like to convince the PICKit 2 firmware developer
that something is wrong even though it is now working under
FreeBSD. Could we see the reason for the stall from the following
USB log?

===[mcuee] ~ # dmesg | grep ugen
ugen0: <Microchip Technology Inc. PICkit 2 Microcontroller Programmer,
class 0/0, rev 2.00/0.01, addr 126>
ugenopen: flag=1, mode=8192
ugenioctl: cmd=40125569
ugenclose: flag=1, mode=8192
ugenopen: flag=3, mode=8192
ugenioctl: cmd=80045572
ugenioctl: cmd=c018556f
ugenioctl: cmd=80045572
ugenioctl: cmd=c018556f
ugenioctl: cmd=80045572
ugenioctl: cmd=c018556f
ugenioctl: cmd=80045572
ugenioctl: cmd=c018556f
ugenclose: flag=3, mode=8192
ugenopen: flag=3, mode=8192
ugenioctl: cmd=80045565
ugen_set_config: configno 1, sc=0xc31ad800
ugenclose: flag=0, mode=0
ugenopen: flag=3, mode=8192
ugenioctl: cmd=80045572
ugenwrite:
ugenwrite: transferred 64 bytes
ugenioctl: cmd=80045572
ugenwrite:
ugenwrite: transferred 64 bytes
ugenioctl: cmd=80045572
ugenioctl: cmd=80045571
ugenread:
ugen_open_pipe_read: interrupt open done
ugenclose: flag=3, mode=8192
ugenclose: flag=3, mode=8192


On 7/8/07, M. Warner Losh <imp at bsdimp.com> wrote:
> : > Why FreeBSD sends out the clear stall feature request for PICKit 2?
> :
> : Therefore it must be a 'protocol stall' and FreeBSD does not need to
> : send a clear feature request for the endpoint 0 to PICkit 2.
>
> I need to look it up, but I believe that a clear endpoint stall also
> resets the toggle, and that was the bug that was tracked down.
>
> Remind me when is this clear endpoint stall sent?  In 7.x we don't
> send one on pipe open unless the device is quirked to require one.  On
> RELENG_6, at least as of today, we never send one on the open.
>

I am using the alternative stack from Hans and 6.2 Stable version. So
maybe there is a difference here.

Xiaofan