[USRP-users] X300 PCIe Driver Issues

Peter Witkowski pwitkowski at gmail.com
Wed Sep 10 09:43:45 EDT 2014


Marcus,

I just ran a really simple test.  I ran "netcat localhost 5444" which is
the port that the NI RIO RPC server connects to based on the message that
gets printed during start up of uhd_rx_cfile and also based on what I'm
seeing on Wireshark.

Wireshark confirms that using netcat, I am able to establish a TCP
connection with localhost on port 5444 without any issues with all physical
network devices disconnected.  However, any UHD related application fails.

At this juncture, I'm strongly considering reconfiguring my system to run
on 10GigE given the issues that I've had setting up PCIe.  Overall, I'm
less concerned about this issue as the work around is readily available.
The other issue I highlighted in my original post is more of a deal-breaker
for me given that there seems to be significant software instability
related to how overflows are handled for PCIe.

On Wed, Sep 10, 2014 at 8:37 AM, Marcus Müller <usrp-users at lists.ettus.com>
wrote:

>  Peter,
> my gut feeling is that Ubuntu brings down central parts of the network
> stack as soon as it think it should be offline, and that somehow kills the
> rio functionality. Now, if I'm not mistaken, the only part that's somehow
> related to networking might be the NI RIO RPC server, listening on port
> 11296.
>
> Now, in a state of everything running, could you do a
> sudo netstat -l -n|grep 11296
> I hope to find out that the RPC server binds to a address it shouldn't
> use, which in turn get's taken down when Ubuntu detects offline state. If
> that doesn't show anything, maybe
> sudo netstat -l -p
> outputs any relevant processes...
>
> If that doesn't help, you could set up a virtual device that is always
> (virtually) connected, and see if that fools Ubuntu.
>
> Greetings,
> Marcus
>
>
> On 10.09.2014 00:09, Peter Witkowski via USRP-users wrote:
>
> Ashish,
>
> I have installed everything correctly (to my knowledge and following the
> guide), and (like I mentioned in my original message) everything seems to
> be partially working.  I have the ability to find the device if I have a
> physical network connection made from the host computer to any network (the
> OS has to register a connection, even a dummy one will do).  I also have
> the ability to retrieve samples although there is still the error where
> when an overflow occurs, the process hangs versus printing a "O."  Also, I
> am able to verify that this issue goes away when using 1 GigE Ethernet (I
> get a lot of overflows at my data rate though).
>
> Marcus,
>
> That is correct.  Any dummy Ethernet connection will do.  I have even
> experimented with bridging eth0 and eth1 with a patch cable.  As long as
> Ubuntu registers the connection as "connected" I can talk to the device
> over PCIe.  I do not have an Ethernet line connected to the USRP during
> these tests.  What's interesting is that if I remove the physical
> connection and quickly run uhd_find_devices or uhd_usrp_probe, the device
> will be present.  However, when Ubuntu registers that the Ethernet
> connection is now "disconnected" I can no longer talk to the device over
> PCIe.
>
> That said, my bigger issue right now is the hanging when an overflow occurs
> versus just printing the "O."
>
> On Tue, Sep 9, 2014 at 4:46 PM, Ashish Chaudhari <ashish.chaudhari at ettus.com
>
>  wrote:
>
>   Hi Peter,
>
> PCI Express functionality for the X300/X310 is independent of your host
> network settings and connections. Can you please confirm that you have done
> everything in the PCIe setup guide:http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux
>
> Also please be aware that you have to run the following command every time
> you reboot your host computer:
> sudo /usr/local/bin/niusrprio_pcie start
>
> Best,
> Ashish
> On Sep 9, 2014 12:50 PM, "Marcus D. Leech via USRP-users" <usrp-users at lists.ettus.com> wrote:
>
>
>   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> <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> 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 Witkowskipwitkowski at gmail.com
>
>
> ______________________________
> _________________
> USRP-users mailing listUSRP-users at lists.ettus.comhttp://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 Consortiumhttp://www.sbrac.org
>
>
> _______________________________________________
> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> --
> Peter Witkowskipwitkowski at gmail.com
>
>
> _______________________________________________
> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Peter Witkowskipwitkowski at gmail.com
>
>
> _______________________________________________
> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing listUSRP-users at lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 
Peter Witkowski
pwitkowski at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140910/983ade3e/attachment-0002.html>


More information about the USRP-users mailing list