[USRP-users] X300 PCIe Driver Issues
Marcus D. Leech
mleech at ripnet.com
Tue Sep 9 15:27:07 EDT 2014
On 09/09/2014 03:20 PM, Peter Witkowski via USRP-users wrote:
> I receive a runtime error with a network cable disconnected. For some
> reason, the driver fails to have the ability to pass packets on the
> loopback interface with an Ethernet cable disconnected.
> Here's exactly what's going on:
> user at new-tower:~$ uhd_usrp_probe --args "resource=RIO0"
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.002-82-g9d4167d9
> Error: RuntimeError: x300_find_pcie: Error enumerating NI-RIO devices.
> A connection could not be established to the specified remote device
> manager. Ensure that the devices are on, that NI-USRPRIO software is
> installed, and that the USRPRIO server is running and properly
> configured. (Error code -63040)
> With a network cable connected (doesn't matter if it's an internal
> network or external or even if my host machine is the sole machine
> plugged into a switch) it works just fine.
I'm wondering if this has something to do with resolving hostnames,
including 'localhost'. If your computer is disconnected, and your DNS
configuration requires everything to get resolved by your DNS server,
perhaps what's going on is that the code fails when it tries to connect
With your network cable disconnected, what happens if you try:
> On Tue, Sep 9, 2014 at 1:18 PM, Marcus D. Leech via USRP-users
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
> On 09/09/2014 12:41 PM, Peter Witkowski via USRP-users wrote:
>> I recently contacted Ettus support regarding this issue, but I
>> was wondering if perhaps the e-mail list could help me out sooner
>> or even confirm the issues that I am having.
>> I currently have an X300 that is having some issues being
>> connected over PCIe.
>> First, I have an issue where the driver seems to hang in
>> instances where an overflow is encountered. That is, if I run
>> uhd_rx_cfile (or any other application for that matter that is
>> receiving data) and an overflow is encountered, the application
>> hangs and stops writing to disk. No "O" characters are printed.
>> However, once an overflow is properly caught and handled (i.e.,
>> "O" characters are printed) I have no more issues with the driver
>> hanging for the rest of that power cycle. From that point
>> forward all overflows are properly handled. If I cycle power on
>> the device or my host machine, the problem comes back. I tried
>> to repeat this issue over Ethernet, and overflow errors are
>> always properly printed and handled.
>> Second, the PCIe driver requires an Ethernet connection. That
>> is, if I unplug a network connection, I cannot run
>> uhd_find_devices. I can ping the loopback address just fine and
>> have verified that the loopback interface is active, but I cannot
>> run uhd_find_devices if my Ethernet connection is disconnected.
>> I am running everything on a fresh install of Ubuntu 14.04 and
>> have verified that I have the latest FPGA image installed on the
>> Please let me know what I should try to alleviate the issues that
>> I am having. Thank you in advance for your help.
>> Peter Witkowski
>> pwitkowski at gmail.com <mailto:pwitkowski at gmail.com>
>> USRP-users mailing list
>> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> I can't answer about the hanging isuee, but if you:
> uhd_usrp_probe -args "resource=RIO0"
> That should always work if things are setup correctly.
> I'm not sure what "uhd_find_devices" doesn't include the RIO
> resources in its "list of things to try", but to be honest, I
> vastly prefer *explicit*
> device naming, rather than implicit "find me a usrp". If one
> has more than one USRP on a system, then implicit naming is nearly
> what you want anyway....
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> USRP-users mailing list
> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
> Peter Witkowski
> pwitkowski at gmail.com <mailto:pwitkowski at gmail.com>
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users