host: Fix RFNoC graph action queue lockup on action exceptions #730
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Details
Description
Processing of the action queue gets locked up when any action being executed in the
send_action
call throws an exception. Exceptions are not caught in the loop handling the action queue, resulting in thehandling_ongoing
queue locking flag to never be released. Any subsequent call toenqueue_action
will return on the early exit with the assumption that we're already handling the actions, yet the previous handler exited with an exception.This fix uses a RAII wrapper rather than a manually claimed and released atomic flag to ensure that the handling_ongoing will be released even under exceptional conditions.
Related Issue
Relates to issue #611
Which devices/areas does this affect?
UHD hosts using RFNoC graph
Testing Done
X310 with dual 10GbE links to server, running both RF inputs at 200MHz sample rate using 2x RX streamers.
Stress the server with CPU load (can use
stress-ng
), inducing UDP packet drops. (Also relates to #611, which stressed the link using iperf, probably also causing UDP packet drops).At some point (difficult to reproduce, but does happen every so often), one of the RX streamers will experience an overrun, which calls the _overrun_handler -> ACTION_KEY_RX_RESTART_REQ which calls
get_time_now()
, doing a peek64 to the device. Thispeek64
then throws an exception due to an ACK timeout.This exception is caught all the way up in thread that called
recv
on the RX streamer, but the stream is irrecoverable since the graph action queue is locked up.Checklist
MPM compat, noc_shell, specific RFNoC block, ...)