USRP NI RIO session/transport initialization error (Error code -63150)

Hi everyone. I have encountered a problem have not found a solution on the internet so far. The settings is shown as follows:

We use PCIe for the connection between our PC and USRP X310. And the Linux system of PC is Ubuntu 20.04. We use radioconda to install gnuradio 3.8 and UHD 3.15. And the Python version is Python 3.8.

Then we use “uhd_find_devices” and the USRP can be detected. But then we use “uhd_usrp_probe”, the following errors occurred:
Error: RuntimeError: Could not create nirio_zero_copy transport. Unknown error. (Error code -63150)

Cannot find the solutions over Internet. I Wonder if this is a NI RIO driver problem or some other problems.
Many thanks.

@flow233-ai

Hi @flow233-ai ,

have you followed the instructions from the manual page Linux NI RIO Installation and Usage? You need the NI RIO driver correctly installed for the nirio_zero_copy transport to function.

The latest version of the NI Linux Device Drivers (2024 Q4) is available here: https://www.ni.com/de/support/downloads/drivers/download.ni-linux-device-drivers.html#548386

The download provides the archive NILinux2024Q4DeviceDrivers.zip which contains ni-ubuntu2004-drivers-2024Q4.deb. You need to install it (sudo dpkg -i ni-ubuntu2004-drivers-2024Q4.deb) and then follow the further steps from the "Linux NI RIO Installation and Usage" manual page (starting at the section "Update package information").

Please note: after installation (and each time the X310 is disconnected/reconnected), a reboot of the host PC is required, because the PCIe connection does not support hotswapping, as noted in the manual:

Hot-Plugging and Power-Cycling

The USRP X3x0, NI USRP-294x and NI USRP-295x devices cannot be hot-swapped when connected over PCI Express. Unplugging the PCI Express connection or powering the device should be done only after powering off the host computer.

Regards,
Jörg

This might be a legit bug (even on more recent UHD versions). Can you use Ethernet for the time being? It's rare that PCIe will do anything for you that Ethernet cannot (on the X310, at least).

@flow233-ai

Hi @flow233-ai ,

have you followed the instructions from the manual page Linux NI RIO Installation and Usage? You need the NI RIO driver correctly installed for the nirio_zero_copy transport to function.

The latest version of the NI Linux Device Drivers (2024 Q4) is available here: https://www.ni.com/de/support/downloads/drivers/download.ni-linux-device-drivers.html#548386

The download provides the archive NILinux2024Q4DeviceDrivers.zip which contains ni-ubuntu2004-drivers-2024Q4.deb. You need to install it (sudo dpkg -i ni-ubuntu2004-drivers-2024Q4.deb) and then follow the further steps from the "Linux NI RIO Installation and Usage" manual page (starting at the section "Update package information").

Please note: after installation (and each time the X310 is disconnected/reconnected), a reboot of the host PC is required, because the PCIe connection does not support hotswapping, as noted in the manual:

Hot-Plugging and Power-Cycling
The USRP X3x0, NI USRP-294x and NI USRP-295x devices cannot be hot-swapped when connected over PCI Express. Unplugging the PCI Express connection or powering the device should be done only after powering off the host computer.

Regards, Jörg

I have tried reinstall the NI RIO Driver. And it failed.
So maybe I would like to use 10 Gigabit network card for connection.

This might be a legit bug (even on more recent UHD versions). Can you use Ethernet for the time being? It's rare that PCIe will do anything for you that Ethernet cannot (on the X310, at least).

Yes. I think I would like to use this method.

Something else you can try (if you want to stick with PCIe) is to use Ubuntu 20.04, which looks like it might be working under some circumstances.

Something else you can try (if you want to stick with PCIe) is to use Ubuntu 20.04, which looks like it might be working under some circumstances.

I‘ve tried with Ubuntu20.04 as mentioned above. But it failed.

OK, that's interesting. Thanks for confirming. I had somehow misread your original report as "24.04".

@flow233-ai

@flow233-ai Did you manage to resolve this problem? I am having a very similar issue (slightly different error message tho) - trying to run uhd_find_devices works but running uhd_usrp_devices results in a RIO session error:

gnb@xgoss-host:~/srsRAN_Project/build4ac5300/apps/gnb$ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; 
UHD_4.7.0.0-0ubuntu1~jammy1
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
    serial:
    fpga: HG
    name:
    product: X310
    resource: RIO0
    type: x300

gnb@xgoss-host:~/srsRAN_Project/build4ac5300/apps/gnb$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; 
UHD_4.7.0.0-0ubuntu1~jammy1
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
[INFO] [X300] Using LVBITX bitfile 
/usr/share/uhd/images/usrp_x310_fpga_HG.lvbitx
Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown 
error. (Error code -63150)

I am discussing this issue also on the usrp mailing list: https://www.mail-archive.com/usrp-users@lists.ettus.com/msg17849.html

For context:

I am using Ubuntu 22.04
I have an X310 connected via PCIe
The nisrpriorpc service seems to be running fine, when checking via systemctl

I don't understand this issue, and I was also unable to find anything about it online.

Hi Everyone,

I am trying to connect a USRP-2952 (X310) to a host machine through PCIe running on Linux Ubuntu 22.04. I followed the driver installation instructions from the Ettus documentation available here:
https://files.ettus.com/manual/page_ni_rio_kernel.html

I downloaded and installed the NI Linux Device Drivers version 2025 Q4 and followed all the steps exactly as mentioned in the documentation above. For the PCIe connection, I am using an NI PCIe-8371 MXI-Express controller card on the host machine and an MXI-Express x4 cable connected to the USRP.

My UHD version is 4.8.0 (built from source for using Openairinterface) and the Kernel version is 6.8.0-90-generic. The system is able to detect the device correctly using uhd_find_devices, but uhd_usrp_probe fails with a RIO session initialization error. I have attached the terminal logs and screenshots for reference.

When I run the following command:
uhd_usrp_probe

I get this output:

[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; UHD_4.8.0.HEAD-0-g308126a4
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
[INFO] [X300] Using LVBITX bitfile /usr/local/share/uhd/images/usrp_x310_fpga_HG.lvbitx
Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown error. (Error code -63150)

I verified that the NI USRP RIO service is running correctly:

sudo systemctl status niusrpriorpc.service
● niusrpriorpc.service - National Instruments USRP RIO Service
Loaded: loaded (/lib/systemd/system/niusrpriorpc.service; enabled; vendor preset: enabled)
Active: active (running)

The device is successfully detected using:
sudo uhd_find_devices

It shows:

Device Address:
serial: 31082D6
fpga: HG
product: X310
resource: RIO0
type: x300

So the USRP is clearly discovered over PCIe, but initialization fails during RIO session creation when running uhd_usrp_probe.

I also came across the PCIe note in the Ettus documentation which says that X300/X310 devices must be powered on before system boot and cannot be hot-plugged over PCIe. I have ensured that the USRP is powered ON before booting the host machine.

Has anyone faced a similar issue on Ubuntu 22.04 ? Any guidance, workaround, or known compatibility issues would be greatly appreciated.
I'm discussing this also on the emailing list (https://mail-archive.com/usrp-users@lists.ettus.com/msg18658.html)
Thank you very much for your support.
Vishwanath



vishwanath@vishwanath:~/gnbarea$ sudo systemctl status niusrpriorpc.service
● niusrpriorpc.service - National Instruments USRP RIO Service
     Loaded: loaded (/lib/systemd/system/niusrpriorpc.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2026-01-20 18:04:12 IST; 26min ago
   Main PID: 695 (niusrpriorpc)
      Tasks: 5 (limit: 28597)
     Memory: 25.1M
        CPU: 4.794s
     CGroup: /system.slice/niusrpriorpc.service
             └─695 /usr/sbin/niusrpriorpc

Jan 20 18:04:10 vishwanath systemd[1]: Starting National Instruments USRP RIO Service...
Jan 20 18:04:12 vishwanath systemd[1]: Started National Instruments USRP RIO Service.
vishwanath@vishwanath:~/gnbarea$ 
vishwanath@vishwanath:~/gnbarea$ sudo uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; UHD_4.8.0.HEAD-0-g308126a4
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
    serial: 31082D6
    fpga: HG
    name: 
    product: X310
    resource: RIO0
    type: x300


vishwanath@vishwanath:~/gnbarea$ sudo uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; UHD_4.8.0.HEAD-0-g308126a4
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
[INFO] [X300] Using LVBITX bitfile /usr/local/share/uhd/images/usrp_x310_fpga_HG.lvbitx
Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown error. (Error code -63150)
vishwanath@vishwanath:~/gnbarea$

Similar issues with a USRP X310 over MXI with a PCIe-8371 card on Ubuntu 24.04 LTS:

Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown error. (Error code -63150)
Error: RuntimeError: x300_impl: Could not initialize RIO session. A fault on the network caused the RPC operation to fail. (Error code -63042)

Setup:

USRP X310 connected over MXI with a PCIe-8371 card. Ubuntu 24.04 LTS x86_64 with Kernel 6.8.0-90-generic
UHD 4.9.0.0+ds1-1~noble2 and GNU Radio 3.10.12 stack installed via the ppa:gnuradio/gnuradio-releases repository
NI drivers 2025 Q4 installed as described here: https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_pcie

Description:
The USRP X310 is discoverable using "uhd_find_devices" and shows up correctly as resource RIO0. It's correctly enumerated in lspcie using niusrpriok drivers and the niusrpriopc service is running. However, everything beyond that does not work, i.e. any flowgraph fails. Even the "uhd_usrp_probe" fails with the following after a clean reboot:

$ uhd_usrp_probe 
[INFO] [UHD] linux; GNU C++ version 13.3.0; Boost_108300; UHD_4.9.0.0+ds1-1~noble2
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
[INFO] [X300] Using LVBITX bitfile /usr/share/uhd/4.9.0/images/usrp_x310_fpga_HG.lvbitx
Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown error. (Error code -63150)

And every subsequent try results in this network fault error:

$ uhd_usrp_probe 
[INFO] [UHD] linux; GNU C++ version 13.3.0; Boost_108300; UHD_4.9.0.0+ds1-1~noble2
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
[INFO] [X300] Using LVBITX bitfile /usr/share/uhd/4.9.0/images/usrp_x310_fpga_HG.lvbitx
Error: RuntimeError: x300_impl: Could not initialize RIO session. A fault on the network caused the RPC operation to fail. (Error code -63042)

AI suggests:

USRP X310 + MXI requires old kernels. Ubuntu 24.04 is currently too new. Once the kernel/NI ABI mismatch exists, nothing in user space can fix it.

@VishwanathKoushik-code

@VishwanathKoushik-code @dominikheinz @flow233-ai I think it would help if you could add the kernel version to your reports in addition to the rio driver and ubuntu versions

@mbr0wn If this is a collection of issues with RIO driver as you said on the mailing list, I think it would be good to change the issue title to capture the variety of error messages, e.g. "USRP NI RIO session/transport initialization error (Error code -63150)", as the code seems to be common to all reports so far.

That's a great suggestion.

Working X310 + PCIe-8371 (MXI) on Arch Linux / kernel 7.2 / UHD 4.8 — root causes for the pre-`-63150` failures, and no `-63150` afterwards

First: thanks everyone in this thread — it was the only map of this territory. We finally got the full path working and wanted to share what was actually broken at each stage, because most of our failures happened before the -63150 stage discussed here, and at least two of the root causes appear to be unknown in this thread.

Result: uhd_find_devices → resource=RIO0; uhd_usrp_probe completes and loads usrp_x310_fpga_HG.lvbitx over PCIe (FW 6.1 / FPGA 39.3, 200 MHz); benchmark_rate runs clean at the full single-channel host rate of the HG image: RX 10/50/100 MS/s and TX 100 MS/s, each 20 s, ~2×10⁹ samples per 100 MS/s run, 0 dropped / 0 overruns / 0 underruns / 0 sequence errors (~3.2 Gbit/s sustained — far beyond the 1 GbE port). Stack: Arch kernel 7.2.11, NI Linux Device Drivers 2026 Q4 (ni-usrp-rio 26.8.0, DKMS), UHD 4.8.0 self-built (GCC 16 / Boost 1.92). Notably we did not hit -63150 at any point — once everything below UHD was complete, session open, FPGA download and streaming all worked first try. So 7.2 + 26.8 + UHD 4.8 is a data point that the session-init failure is not universal on new kernels.

For those stuck earlier in the pipeline, here are the five things that were broken for us, roughly in discovery order:

1. The PCIe slot itself. In an x1-electrical slot — including one that is physically full-length! — the MXI link never trains: the PEX 8608 downstream port reads Width x0 / DLActive- forever and the 8371 bracket LED stays solid amber (= "power OK, no cable link" per NI's LED spec). No driver, pcie_aspm=off, cold boot, rescan, secondary bus reset or manual link retrain will fix this — we tried all of them on the wrong slot. Moving the card to a real x4-electrical slot gave x4 on both PEX ports and 1093:c4c4 enumerated instantly. If your lspci shows the PLX switch but no NI endpoint, check the link width and your slot's electrical lanes before touching software.

2. Enumeration is a daemon chain since the 20.x drivers. libniriodevenum is just a client. You need three services: nisvcloc → NiRioServer (nirioserver) → niusrpriorpc. The dependency closure of ni-usrp-rio does not include the first two — we had to install ni-rio-server and ni-service-locator explicitly.

3. Deb postinst side effects (we installed manually on Arch). Two things dpkg would have done: create /var/lib/nirio/{lock,ini,plugins} etc. (without lock/, NiRioServer dies with -50209 because it can't O_CREAT its lock file), and install /etc/nirio/plugins/NiRioSrvEnumeratorPlugin.ini from the ni-rio package. That ini is the enumerator-plugin registration — without it the plugin manager loads zero plugins and enumeration fails forever. This was our last missing piece and I don't think it's documented anywhere outside NI's packaging scripts.

4. -50204 is a server-side status, not a connection error. UHD reports it as RpcConnectionError, which points you at the transport. In fact the RPC exchange completes and the service returns -50204 as the enumeration result. We wasted significant time on boost-serialization "archive version" mismatches (handshake logs Server Archive Version = 19, Client = 20) — that's a red herring: payloads are text_archive + no_header, version-independent. We wrote a ~60-line raw-socket probe for the RPC protocol (24-byte handshake struct, function 256 = enumerate) that prints the server's actual payload — 0 1 0 0 0 4 RIO0 ... when healthy. It's in the writeup; it will tell you in 10 seconds which layer is lying to you.

5. localhost must resolve to IPv4-reachable. niusrpriorpc binds 0.0.0.0:5444 only; if your resolver hands out ::1 first (ours did, due to an nsswitch.conf quirk), the UHD client gets connection-refused and reports — you guessed it — -50204, this time genuinely from the connection layer.

Also worth knowing: the five kernel modules (nikal, nibds, nistreamk, NiRioSrv, niusrpriok) from the 2026 Q4 packages build and load on 7.2 unpatched, including the two binary-blob modules — NI's KAL does runtime kernel-capability detection. And UHD itself needs no NI userspace library; it speaks the RPC protocol and kernel ioctls itself, so "UHD built without niusrprio" is not a thing to worry about — but UHD 4.8 needs a few patches for GCC 16 / CMake 4 (all mechanical; listed in the writeup).

Full recipe, error-code cheat sheet, the raw RPC probe source, and the UHD 4.8-on-modern-toolchain patch list: https://github.com/r2-lee/x310-pcie-8371-linux

Happy to answer questions here. Many thanks to the maintainers, and to everyone who shared logs and configs upthread — the trick of running niusrpriorpc --log-level verbose in the foreground, documented earlier in this issue, was a key tool for us too.

Config notes: Gigabyte Z790 D DDR4; X310 with dual UBX-160; the flash still holds the NI firmware image and is untouched — PCIe sessions load the UHD-side lvbitx into the FPGA per session, so the Windows/NI setup on the same machine keeps working.

Navigation Menu

Repository navigation

USRP NI RIO session/transport initialization error (Error code -63150) #818

Working X310 + PCIe-8371 (MXI) on Arch Linux / kernel 7.2 / UHD 4.8 — root causes for the pre-`-63150` failures, and no `-63150` afterwards

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

USRP NI RIO session/transport initialization error (Error code -63150) #818

Description

Activity

joergho commented on Dec 4, 2024

mbr0wn commented on Dec 5, 2024

flow233-ai commented on Dec 6, 2024

flow233-ai commented on Dec 6, 2024

mbr0wn commented on Dec 10, 2024

flow233-ai commented on Dec 10, 2024

mbr0wn commented on Dec 10, 2024

dominikheinz commented on Jan 27, 2025

VishwanathKoushik-code commented on Jan 20, 2026

eltos commented on Jan 21, 2026

eltos commented on Jan 21, 2026

mbr0wn commented on Jan 22, 2026

r2-lee commented on Oct 27, 2026

Working X310 + PCIe-8371 (MXI) on Arch Linux / kernel 7.2 / UHD 4.8 — root causes for the pre--63150 failures, and no -63150 afterwards

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Working X310 + PCIe-8371 (MXI) on Arch Linux / kernel 7.2 / UHD 4.8 — root causes for the pre-`-63150` failures, and no `-63150` afterwards