USRP2: fix "RuntimeError: fifo ctrl timed out looking for acks"

[mikehaben69]

Pull Request Details

Description

Deleted "this->peek32(0)" from usrp2_fifo_ctrl_impl destructor - fixes "RuntimeError: fifo ctrl timed out looking for acks", and enables USRP2 to operate successfully with GnuRadio. This bug has been reported on the mailing list multiple times (e.g. this 2018 thread, this current thread ), but not previously addressed as the USRP2 is regarded as obsolete.

Related Issue

Which devices/areas does this affect?

USRP2, operation with GnuRadio.

Testing Done

Patch tested against UHD v4.1.0.5 under Ubuntu Linux 22.04, with GnuRadio 3.10.1.1 (example GnuRadio Companion script with USRP2 acting as a receiver). Also fixes the same error seen in console output from the "uhd_usrp_probe" utility.

Checklist

• I have read the CONTRIBUTING document.
• My code follows the code style of this project. See CODING.md.
• I have updated the documentation accordingly.
• I have added tests to cover my changes, and all previous tests pass.
• I have checked all compat numbers if they need updating (FPGA compat,
  MPM compat, noc_shell, specific RFNoC block, ...)

[github-actions]

CLA Assistant Lite bot:
Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request}

[mikehaben69]

I have read the CLA Document and I hereby sign the CLA.

[mbr0wn]

Does this error pop up at the end of the application, or at the beginning (or some other time where it's not supposed to occur)? If it occurs at the end, the SAFE-call macro is in charge of making sure it doesn't have any ill effects.

[mikehaben69]

It occurs at the end, but it causes GNURadio Companion to fail to run any GRC graph that incorporates USRP2 source or sink. This patch enables GRC graphs including USRP2 to run successfully, and doesn't appear to have any nasty side-effects.

[mbr0wn]

It occurs at the end, but it causes GNURadio Companion to fail to run any GRC graph that incorporates USRP2 source or sink.

How does it do that? Does it stop you from re-running the USRP? Or is GRC unhappy with the error output?

doesn't appear to have any nasty side-effects.

This patch does have the side-effect that it doesn't clear the FIFO command queue anymore. This is probably fine most of the time, but might have other side-effects for the next program trying to use this USRP.

I would agree that crashing GRC is potentially a worse side effect than maybe-some-FIFOs-aren't-fully cleared, but the UHD_SAFE_CALL() is supposed to avoid those bad effects. So other than the ugly output, I'm still not sure where the issue is. After all, there is a legitimate problem somewhere here (UHD should be able to get that ACK), and it's nice to be told about it. Maybe there's a way to figure out what breaks GRC, if the SAFE_CALL macro isn't doing the trick.

[mikehaben69]

From memory (because I don't have the equipment set up right now), GRC running a graph does a "uhd_usrp_probe" first, in order to find the USRP sink or source - when uhd_usrp_probe returns a "fail" error-code (and prints to stderr "RuntimeError: fifo ctrl timed out looking for acks"), GRC assumes that the USRP is not useable and and doesn't try to set up the connection to it.

[mbr0wn]

Excuse us for leaving this PR open for so long. As I mentioned before, the printing of

  [ERROR] [UHD] Exception caught in safe-call.
    in virtual usrp2_fifo_ctrl_impl::~usrp2_fifo_ctrl_impl()
    at /build/uhd-YDOjRX/uhd-3.13.0.1/host/lib/usrp/usrp2/usrp2_fifo_ctrl.cpp:54
  this->peek32(0); -> RuntimeError: fifo ctrl timed out looking for acks

does not constitute an error. Maybe we should be demoting the log level to 'WARNING' since we deliberately choose to not propagate the exception. We will therefore leave this unchanged.