22 messages in org.freebsd.freebsd-usblibusb usb_interrupt_read hangs under...| From | Sent On | Attachments |
|---|---|---|
| Xiaofan Chen | Apr 3, 2007 11:54 am | |
| Hans Petter Selasky | Apr 3, 2007 12:26 pm | |
| Xiaofan Chen | Apr 3, 2007 1:34 pm | |
| Hans Petter Selasky | Apr 3, 2007 2:42 pm | |
| Xiaofan Chen | Apr 3, 2007 11:55 pm | |
| Hans Petter Selasky | Apr 4, 2007 7:37 am | |
| Xiaofan Chen | Apr 4, 2007 11:34 am | |
| Xiaofan Chen | Jul 4, 2007 5:32 pm | |
| Hans Petter Selasky | Jul 5, 2007 3:24 pm | |
| Xiaofan Chen | Jul 8, 2007 12:25 am | |
| M. Warner Losh | Jul 8, 2007 5:11 am | |
| Xiaofan Chen | Jul 8, 2007 1:16 pm | |
| Xiaofan Chen | Jul 8, 2007 4:31 pm | |
| M. Warner Losh | Jul 8, 2007 8:00 pm | |
| Hans Petter Selasky | Jul 9, 2007 4:35 pm | |
| Xiaofan Chen | Jul 10, 2007 1:27 am | |
| Xiaofan Chen | Jul 13, 2007 10:32 pm | |
| Hans Petter Selasky | Jul 15, 2007 9:18 am | |
| Xiaofan Chen | Jul 16, 2007 3:44 pm | |
| Hans Petter Selasky | Jul 17, 2007 5:55 am | |
| Xiaofan Chen | Aug 11, 2007 4:45 am | |
| Xiaofan Chen | Sep 22, 2007 3:47 am |
| Subject: | libusb usb_interrupt_read hangs under FreeBSD | |
|---|---|---|
| From: | Xiaofan Chen (xiao...@gmail.com) | |
| Date: | Jul 16, 2007 3:44:27 pm | |
| List: | org.freebsd.freebsd-usb | |
On 7/15/07, Hans Petter Selasky <hsel...@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 <im...@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