Looks like DATA OUT toggling on BULK endpoints has a bug
>>>>>>>> SYSTEM INFO (HOST) <<<<<<<<<<
> sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux gmcnutt-lx 2.4.17 #1 SMP Wed Jan 2 17:59:24 MST 2002 i686 unknown
Gnu C 2.96
Gnu make 3.79.1
binutils 2.10.91.0.2
util-linux 2.10s
mount 2.10r
modutils 2.4.2
e2fsprogs 1.19
reiserfsprogs 3.x.0f
pcmcia-cs 3.1.22
PPP 2.4.0
Linux C Library 2.2.2
Dynamic linker (ldd) 2.2.2
Procps 2.0.7
Net-tools 1.57
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded usbserial
> grep USB .config
# USB support
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# Miscellaneous USB options
# CONFIG_USB_DEVICEFS is not set
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_LONG_TIMEOUT is not set
# USB Controllers
CONFIG_USB_UHCI_ALT=y
# CONFIG_USB_OHCI is not set
# USB Device Class drivers
# CONFIG_USB_AUDIO is not set
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# USB Human Interface Devices (HID)
# Input core support is needed for USB HID
# USB Imaging devices
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# USB Multimedia devices
# Video4Linux support is needed for USB Multimedia device support
# USB Network adaptors
# USB port drivers
# USB Serial Converter support
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# USB Miscellaneous drivers
>>>>>>> DESCRIPTION <<<<<<<
This is 100% reproducible, but I'm using an experimental device. The
special property of this device is that it *always* NAKs packets sent
to one of its bulk endpoints (at least it should, but more on that
later...).
I load a usbserial module built for generic support and give it the
product and vendor to recognize my device. On cable attachment
enumeration proceeds as expected and /dev/ttyUSB0 becomes my device.
I start a CATC trace and on the host:
$ echo hello > /dev/ttyUSB0
As expected, the echo command blocks. After a second or two I kill it
with two Ctrl-C's from the keyboard (for some reason, one is not enough).
The CATC trace shows all the DATA OUT packets containing the data are
NAKd, as expected. The data toggle is 0 for all these packets, as
expected.
Now repeat the process. This time, the echo command returns immediately.
The CATC trace shows that the DATA OUT toggle bit is now set to 1. The
device ACKd the packet.
My theory is that the device hardware sees the data toggle of 1 and
mistakenly believes the host lost an ACK and is resending a packet. So
the device ACKs the packet (and probably just discards the data). I'm
not sure how else device hardware can accomodate lost ACKs, so I guess
this is sane behaviour on the part of the device.
If so, then this is probably a bug in the Linux UHCI driver. If I
understand the spec correctly, the host should not advance the toggle bit
unless the packet was ACKd.
I've poked around in the code a bit, and I see a couple of places in
uhci.c where the toggle bit is being messed with, but I'm not sure
how my signaling the process is removing the urb. It seems that at
that point the toggle sequence associated with the urb needs to be
canceled unless it was ACKed by the device.
I don't mean to be impolite, but I do not subscribe to this list. So please
CC replies to [EMAIL PROTECTED]
Regards,
--gmcnutt
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
