Date: Mon, 16 Jul 2007 11:44:46 -0400 From: "Xiaofan Chen" <xiaofanc@gmail.com> To: "Hans Petter Selasky" <hselasky@c2i.net>, "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-usb@freebsd.org Subject: Re: libusb usb_interrupt_read hangs under FreeBSD Message-ID: <a276da400707160844k4d5ffd3fu86dba16e73f3cf23@mail.gmail.com> In-Reply-To: <200707151118.28211.hselasky@c2i.net> References: <a276da400704030427g6fcfdc37u43bdf0fd1cd69ea8@mail.gmail.com> <200707091835.50445.hselasky@c2i.net> <a276da400707131533h4fb77751r2a288007887438a0@mail.gmail.com> <200707151118.28211.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/15/07, Hans Petter Selasky <hselasky@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a276da400707160844k4d5ffd3fu86dba16e73f3cf23>