Comment 299 for bug 1667750

I think I've narrow it down to a minimum.

Using libusb, if you happen to call libusb_control_transfer(), which is synchronous I/O, while there's asynchronous I/O already in progress (usually caused by application error), then the cleanup to the in-progress asynchronous I/O will cause the error.

Ex:
...
libusb_submit_transfer(...); // Start async I/O
...
libusb_control_transfer(...); // Sync I/O
...
libusb_cancel_transfer(...); // .... WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
...

Or, simply

...
libusb_submit_transfer(...); // Start async I/O
...
libusb_control_transfer(...); // Sync I/O
...
libusb_release_interface(...); // Will cleanup async I/O in progress .... WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
...

The thing is that in the example above, even though there's an application error, the behavior is different on different chipset driver.

In the case of HackRF application (which I mentioned above), the application called libusb_cancel_transfer() on exit followed by a libusb_control_transfer. That should work, since the async (streaming) I/O were truminated before sync I/O, but a final callback did a call (by mistake, did not check that the driver was in process of shutting down) to libusb_submit_transfer(). This created a race condition in which if that made it possible to trigger the above bug (made easily reproducible with properly placed 'sleep()' call).