On Mon, 13 Mar 2017, Charles Manning wrote: > Hello > > I have an issue where the first 512-byte high speed bulk transfer > between a custom peripheral and a Linux host is sometimes lost. > > I have the bus attached to a Beagle 480 and I can see the transaction > happening over the bus (IN, DATA, ACK) at the right time but the data > does not show up into userspace buffers. ie. it would seem the data is > getting lost somewhere between the host hardware and user space. > > I've seen on both Ubuntu with 4.4.0 x64 as well as on various Android > ARM platforms (ie commercial Android phones/tablets). > > There are two independently written user space programs that both > exhibit this behaviour: > * Linux PC based application written using libusb. > * Android application written in NDK using ioctls. > > In both cases everything works fine (eg. long term streaming for > hours, orderly start/stopping) except when the process is killed > (swipe app right in Android) or Control C in Ubuntu. > > If the application is killed then the first 512-byte transfer in the > next invocation of the application **might** be lost. > > In our application we're stuffing approx 8 or 9 MBytes of data a > second through the high speed USB link (ie. around 1/7) of the full > bandwidth. The problem occurs approximately 1/7th of the time. > > This leads me to suspect that around 1/7th of the time the process is > being killed during the middle of a transfer and this results in the > host controller being left in a weird state causing the first packet > to be lost. > > Any hints on where to look for this or how to debug further would be > much appreciated. No doubt what happens is that the packet is received by the system, but the process is killed before it can get the packet's contents from the operating system. (Or after it has gotten the packet's contents but before it can do anything with them.) I can assure you that the host controller is not left in any sort of weird state. If you want to prevent this sort of thing from happening, don't just kill the process willy-nilly. Have it catch the signal and set a flag, and have it check this flag at an appropriate place so that it can fetch the contents of any remaining packets before exiting in an orderly manner. Alan Stern -- 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
