> Don't say they "get lost" unless you really mean it. "Get lost" > implies that the packets were sent by the device but not received by > the host (or vice versa). However it's not clear that these packets > were sent in the first place. If they were sent by the host, they > definitely would show up in the usbmon trace. Sorry - after your other explanations it seems that the device is queuing the interrupt data ready for transfer, but the host is never requesting the data. (Or it is being told there is no data available.) >> I hope this explains it a bit better. > > A little, but not enough. Seeing the data will make things a lot > clearer. Here are the traces: http://www.shikadi.net/files/odin/ I began the capture with no device connected, then connected the device (or ran the gadgetfs app.) After the OS finished detecting the device, I waited for 10 or so seconds and ran the application (to make this clear when looking at the timestamps in the files.) For filenames with "win32" in them this was the manufacturer's application, for filenames with "linux" in them this was my own userspace app. My userspace app only sends one control message and reads one interrupt response. To reiterate: hardware-linux: Host receives interrupt messages successfully hardware-win32: Host receives interrupt messages successfully gadgetfs-linux: Host receives interrupt messages successfully gadgetfs-win32: Interrupt message data is never sent to host, the last message is the control one telling the device to make the data available on the interrupt endpoint. Because I find Wireshark helpful at explaining what the USB messages mean, I have been using this for my traces. I have uploaded both usbmon and Wireshark captures. I hope this can shed some light on things, because I'm completely baffled as to why it's not working! Thanks, Adam. -- 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
