I'm using libusb to talk to a low speed serial device on the other end of of a Silicon Labs USB to serial chip set. (Darwin backend on MacOS 10.8.5). The device is kinda like a networking device in that it's logically half duplex and only sends data back if asked. So host sends 12 bytes asking for next packet, device sends back 68 bytes. These are synchronous bulk transfers - Max USB packetize is 64 so it's consecutive 64 and 4 byte USB transfers.
I'm seeing a bug in libusb. Every now and again, (actually, it's pretty often), the device "geeks" and instead of sending back the 68 bytes it sends back 0 or 1 byte and then the bulk read times out. Not a problem really, the host just sends the same previous 12 byte packet out again asking for the same block of 68 bytes again. Sometimes this happens just fine, but a lot of times, the host does not see the next 68 byte packets, and the subsequent calls to libusb_bulk_transfer() also time out until all the "retries" (at the networking level) have been exhausted and the transfer fails.
I've put a USB analyzer on it and I can see the device return the 68 bytes after the "geek" and timeout, so I know it's on the bus, but libusb does not return them in the subsequent libusb_bulk_transfer call.
I've been using libusb 1.0.8 mostly. I tried upgrading to libusb 1.0.9 and it made no difference.
If I compile libusb with ENABLE_DEBUG_LOGGING, it rarely happens. But as soon as I turn it off again, it comes back. It's all very easily repeatable. (FYI I do have ENABLE_LOGGING defined). That says to me that it's a timing issue of some sort with libusb.
If I use the kernel driver supplied by SI, I can get a trace as well, see the "geek" as well, but the kernel driver recovers fine and the subsequent 68 byte packets are returned.
I'll start poking around in the libusb source but I was hoping someone else might have already seen this or might have some more experienced thoughts on where to look.
