George, Thanks for your question.
Since 4f3c8d6eddc272b386464524235440a418ed2029 I'm experiencing this STB race condition. TL;DR an old, cached STB value can be used after a new one is reported in reply to a control message. Hacking up the latest driver code to ignore the cached stb value gets around the issue.
The SRQ notification is an important message and must not be missed in userspace applications. The new implementation does not miss the SRQ event anymore, even when multiple threads are waiting for the SRQ event. Your coding relies on the previous behavior and did not fail for your use case and timing. However we could not develop reliable applications with the previous implementation. There are now two ways to wait for the SRQ event: 1. Using the poll/select method 2. Using the new ioctl USBTMC488_IOCTL_WAIT_SRQ (preferred way) When receiving the SRQ event, you should immediately read the stb with USBTMC488_IOCTL_READ_STB within the same thread to prevent races or reading stale status byte information. More info see: https://github.com/GuidoKiener/linux-usbtmc/blob/master/README.md
My USBTMC device has an interrupt endpoint with a 1ms interval. 1) A query is sent to the USBTMC device. 2) An SRQ is reported via the interrupt endpoint with MAV set. 3) Userspace performs a read to get the reply since MAV is set after being notified by poll().
Did you start reading (read()) without checking the Status Byte after poll() event?
Regards, Guido
