[USRP-users] X300 PCIe Driver Issues

Marcus D. Leech mleech at ripnet.com
Tue Sep 9 15:49:46 EDT 2014


On 09/09/2014 03:43 PM, Peter Witkowski via USRP-users wrote:
> ping localhost works fine regardless of the Ethernet status.
So, just to clarify, so we know where to start looking.   It doesn't 
matter if your network port is actually connected to an X3xx at the time,
   as long as it's "up", you can use the PCIe interface?


>
> On Tue, Sep 9, 2014 at 3:27 PM, Marcus D. Leech <mleech at ripnet.com 
> <mailto:mleech at ripnet.com>> wrote:
>
>     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
>       to "localhost:<rio-port-number>".
>
>     With your network cable disconnected, what happens if you try:
>
>     ping localhost
>
>
>
>>     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:
>>>         Hello,
>>>         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 device.
>>>
>>>         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>
>>>         http://lists.ettus.com/mailman/listinfo/usrp-users_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 never
>>           what you want anyway....
>>
>>
>>         -- 
>>         Marcus Leech
>>         Principal Investigator
>>         Shirleys Bay Radio Astronomy Consortium
>>         http://www.sbrac.org
>>
>>
>>         _______________________________________________
>>         USRP-users mailing list
>>         USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>>     -- 
>>     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>
>>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> -- 
> Peter Witkowski
> pwitkowski at gmail.com <mailto:pwitkowski at gmail.com>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140909/16eb0b5a/attachment-0002.html>


More information about the USRP-users mailing list