aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAaron Rossetto <aaron.rossetto@ni.com>2022-01-21 16:13:28 -0600
committerAaron Rossetto <aaron.rossetto@ni.com>2022-01-21 16:13:28 -0600
commit32cbda4fed71f6340302d8a230979546f6927f32 (patch)
treeae34377efce940e3795ae555e0bb4a902b42ada2
parentb1586ee26b61fedd74e3bc076f7ff58d7a72f615 (diff)
downloaduhd-32cbda4fed71f6340302d8a230979546f6927f32.tar.gz
uhd-32cbda4fed71f6340302d8a230979546f6927f32.tar.bz2
uhd-32cbda4fed71f6340302d8a230979546f6927f32.zip
rfnoc: Ignore errors in ctrlport response packets if ACKs not wanted
In 0caed5529, a change was made to ctrlpoint_endpoint's behavior such that if a client does not care about checking for ACKs on poke or poll operations, the code calls `wait_for_ack()` with a flag indicating that it should not wait for the ACK, but find and remove the corresponding response from the response queue. This prevents the queue from potentially growing endlessly with response packets that the client doesn't even care about. However, this introduced a subtle, undesired behavioral change. When `wait_for_ack()` finds the corresponding response for a request, it also checks the status field of the response to report any errors flagged by the hardware such as invalid command, routing error, etc. Prior to the change mentioned above, since `wait_for_ack()` was never called when the client doesn't want ACKs, the client would never be never notified of any errors associated with the request. However, with the aforementioned change in placd, when `wait_for_ack()` is called to find and remove the unwanted response packet corresponding to the request, errors **are** checked and reported up the user. The behavior change was unearthed by the X410 ZBX CPLD initialization code, which writes an initial value of 0 to all ZBX CPLD registers--even read-only registers. A control request to write a read-only register results in a response with CMDERR in its status field, as it should. However, since the ZBX CPLD register initialization is performed with a `poke32()` operation which by default doesn't wait for ACKs, this was never a problem until the change to drain the response queue inadvertently caused the error to surface. The result is that creating a USRP session or RFNoC graph session to an X410 device is seen to occasionally fail with a 'RuntimeError: RuntimeError: Failure to create rfnoc_graph' message printed to the console. This commit preserves the desired queue-draining behavior, but ignores any error status on the response when it is found and removed from the queue, thus restoring the behavior pre-0caed5529.
-rw-r--r--host/lib/rfnoc/ctrlport_endpoint.cpp8
1 files changed, 8 insertions, 0 deletions
diff --git a/host/lib/rfnoc/ctrlport_endpoint.cpp b/host/lib/rfnoc/ctrlport_endpoint.cpp
index 2078ecce1..3a569fae1 100644
--- a/host/lib/rfnoc/ctrlport_endpoint.cpp
+++ b/host/lib/rfnoc/ctrlport_endpoint.cpp
@@ -453,6 +453,14 @@ private:
// Filter by op_code, address and seq_num
if (rx_ctrl.seq_num == request.seq_num && rx_ctrl.op_code == request.op_code
&& rx_ctrl.address == request.address) {
+ // If we find the response for our request, and the client
+ // has not requested acknowledgements, then simply return,
+ // ignoring any error status in the response. This restores
+ // the pre-0caed5529 behavior.
+ if (!require_ack) {
+ return {};
+ }
+
// Validate transaction status
if (rx_ctrl.status == CMD_CMDERR) {
throw uhd::op_failed("Control operation returned a failing status");