> Instead of trying to recover, you should try to find out what goes > wrong in the first place. Does the host continue to request the > isochronous data? Does the device receive the requests but fail to > send anything back? Does the device send back packets containing no > data? My host continuously receives and, when no packets are actually received, it goes on submitting requests and executing completion handlers in which void packets are found. This happens in the normal execution as well: if "holes" are present within the transfers, the host simply loops and submits new requests. I tryed to avoid such holes to appear, but in order to do that I had to setup the interval value to 64 in the urbs submitted by the host. In this way, no holes appear but a big amount of data is buffered: in fact, when the gadget stops sending data, several seconds (often minutes) are needed for all data to be actually received, that is, host and gadget go on submitting urbs and executing completion handlers with actual_length > 0. I supposed that an excessive amount of buffered data could cause problems to the gadget, due to its limited resources. Therefore I'm trying to reduce the interval to 16, and now the communication doesn't break, but the host executes completion handlers where data is not all included. For example: in a single urb, 2 packets should be normally included, but the host shows some completion handlers where just 1 packet or none is received. I paste here a little portion of the usbmon output: ca32bd80 1397302852 C Zi:4:015:2 0:16:4672:0 2 0:0:0 0:512:512 512 = f8fefcfe eafef0fe fefe0e00 3800fafe 02001200 0e000800 f8fe0400 e0fe0000 ca32bd80 1397302863 S Zi:4:015:2 -115:16:4672 2 -18:0:512 -18:512:512 1024 < ca32bd80 1397306852 C Zi:4:015:2 0:16:4704:0 2 0:0:512 0:512:0 512 = f1ffeeff fafffaff fbff0700 05000a00 ffff0300 15000400 f0ff0400 faff0900 ca32bd80 1397306860 S Zi:4:015:2 -115:16:4704 2 -18:0:512 -18:512:512 1024 < ca32bd80 1397310855 C Zi:4:015:2 0:16:4736:0 2 0:0:0 0:512:0 0 ca32bd80 1397310864 S Zi:4:015:2 -115:16:4736 2 -18:0:512 -18:512:512 1024 < ca32bd80 1397314852 C Zi:4:015:2 0:16:4768:0 2 0:0:0 0:512:512 512 = e2fedcfe f4fef4fe f6fe0e00 0a001400 fefe0600 2a000800 e0fe0800 f4fe1200 ca32bd80 1397314860 S Zi:4:015:2 -115:16:4768 2 -18:0:512 -18:512:512 1024 < ca32bd80 1397318851 C Zi:4:015:2 0:16:4800:0 2 0:0:512 0:512:0 512 = f7ff0100 f3ff0500 f5fffaff 1100f4ff faff0300 06000300 04000100 08000e00 As you can see, some callbacks contain both packets of zero length. How can I see if data is actually being lost or it's just received in successive calls? This solution could work well since the latency and the buffered data now seem to be almost zero, but an excessive amount of lost data could be not tolerable... Thanks for your support, Daniele -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
