libbladeRF: Sync interface does not correctly handle timeouts occurring in the underlying stream #229
Assignees
Comments
jynik
added a commit
that referenced
this issue
Mar 15, 2014
When starting an RX stream, the first N buffers, where N is the number of transfers, will be submitted when the bladerf_stream() call is made. Therefore, it is incorrect to clear IN_FLIGHT status; this will result in an assertion firing in the RX callback. After looking into this, it's become clear that the sync interface does not correctly handle the situation where the underlying async stream starts up. Issue #229 has been opened to further track the associated defect and resolution.
|
This is being worked on in the dev-libbladeRF_v0.15.0 branch. Recovery from RX timeouts have been added in c50f2b8. I'll be further reviewing the TX side of things over the next few nights. |
|
With the closing of issue #232, no further issues have popped up during testing or have been reported. Closing this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The libbladeRF synchronous interface does not correctly handle the situation when a timeout (or other failure) occurs on the underlying asynchronous stream.
In the RX case, the stream will restart and submit buffers, 0 - N, where N is the number of in-flight transfers allowed for the stream. However, the sync_rx call may be currently waiting on some buffer N+M.
A similar mismatch occurs on the TX side.
Some additional logic will need to be added to sync_tx and sync_rx to notify these functions that a timeout has occurred, and that they should just drop their current data and reset their buffers to an initial state. (This is probably best done in check_worker()).
The text was updated successfully, but these errors were encountered: