Under certain yet not fully understood conditions the following can happen: (linux usbmon output)
ffff8b32769c3e40 1199806266 S Bo:2:004:2 -115 12304 = 292b4030 40000000 01c82b00 4b2d4030 40000000 02c82b00 4e344030 40 ffff8b32769c3e40 1199806370 C Bo:2:004:2 0 12304 > ffff8b32769c3e40 1199806378 S Ci:2:004:0 s c0 c7 0000 0000 0020 32 < ffff8b32769c3e40 1199806454 C Ci:2:004:0 0 32 = 10300000 10300000 01000000 00000000 00310000 00310000 09000000 00000000 ffff8b32769c3e40 1199831544 S Ci:2:004:0 s c0 c7 0000 0000 0020 32 < ffff8b32769c3e40 1199831711 C Ci:2:004:0 0 32 = 10300000 10300000 03000000 00000000 00310000 00310000 09000000 00000000
you can see that there is a 25 msec delay between the first and second control transfer and that the 3rd word on the device response sees a change from 01000000 to 03000000.
If for some reasons these delays happen in a session, they happen often, but not for every bulk out transfer. Some of those packets are followed by a single control transfer and the 3rd word in the reply is always 03000000.
I kid you not: if the process is run under strace, then this delay never happens.
There may be a 25ms sleep somewhere in the frontpanel code base or in the cypress code base that does not belong there.
i’d really love to go back solving my own bugs and i am not sure i can come up with a workaround here.
The control transfer is a vendor specific request c0. since cypress reserves a0-af, i suspect this is an opalkelly specific request and i would love to know what it is all about.
thx for your time and attention.
the device in question is a xem7350-k410T, frontpanel version is 5.1.0 x64 ubuntu18.04.
The bug (?) also happens with frontpanel 4.5.0