On Fri, Oct 14, 2022 at 01:20:49PM +0200, Thilo Roerig wrote: > > As Greg mentioned, usbmon is a better way to snoop the data transfers. > > I have continued to investigate the issue using usbmon, but unfortunately, I > could not find any other irregularity, but the jumps in the report id pattern. Did you check the timestamps carefully? In particular, did you examine the times when each transfer was submitted and completed? If two adjacent transfers complete more than one or two microseconds apart, that indicates a problem. Also, do the report IDs show up in the usbmon trace so that you can directly see which ID appears in which transfer? > > The most important thing you should do, to ensure that reports do not > > get lost, is submit a large queue of interrupt transfers in advance. > > Each time a transfer completes, add another submission to the queue. > > > > That way, even if your process loses control of the CPU for some period > > of time, the transfers will continue (unless the period is so long that > > your entire queue gets consumed before the process is able to submit > > more requests). > > Thank you for your help! Initially, I was submitting 4 transfers only. > I'll try to submit more transfers once I start loosing reports. Currently > I am able to get all reports using only 4 transfers. I'm loosing reports > only if I'm debugging with `usbfs_snoop`. In this case, I tried submitting > more transfers, but I was still loosing some reports, so I decided, that > I will try to find another debugging possibility iother then usbfs_snoop. Yeah, probably usbfs_snoop slows everything down so much that it becomes impossible for your program to keep up with device. On the other hand, if you're able to get all the reports (without usbfs_snoop) using only four transfers then it seems like you've solved the problem! Alan Stern
