<div dir="ltr"><div>Marcus,<br><br>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.<br><br>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.<br><br></div><div>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.<br></div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 10, 2014 at 8:37 AM, Marcus Müller <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Peter,<br>
    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.<br>
    <br>
    Now, in a state of everything running, could you do a <br>
    sudo netstat -l -n|grep 11296<br>
    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 <br>
    sudo netstat -l -p <br>
    outputs any relevant processes...<br>
    <br>
    If that doesn't help, you could set up a virtual device that is
    always (virtually) connected, and see if that fools Ubuntu.<br>
    <br>
    Greetings,<br>
    Marcus<div><div class="h5"><br>
    <br>
    <div>On 10.09.2014 00:09, Peter Witkowski
      via USRP-users wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <pre>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 <<a href="mailto:ashish.chaudhari@ettus.com" target="_blank">ashish.chaudhari@ettus.com</a>
</pre>
      <blockquote type="cite">
        <pre>wrote:
</pre>
      </blockquote>
      <pre></pre>
      </div></div><blockquote type="cite"><div><div class="h5">
        <pre>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:
<a href="http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux" target="_blank">http://code.ettus.com/redmine/ettus/projects/uhd/wiki/NI_USRP_RIO_Linux</a>

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" <
<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>> wrote:

</pre>
        </div></div><blockquote type="cite"><div><div class="h5">
          <pre> 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 <a href="mailto:mleech@ripnet.com" target="_blank"><mleech@ripnet.com></a>
wrote:

</pre>
          </div></div><blockquote type="cite"><div><div class="h5">
            <pre> 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@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 <
<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>> wrote:

</pre>
            </div></div><blockquote type="cite">
              <pre><div><div class="h5">  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
<a href="mailto:pwitkowski@gmail.com" target="_blank">pwitkowski@gmail.com</a>


______________________________</div></div>_________________
USRP-users mailing <a href="mailto:listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>

 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://<a href="http://www.sbrac.org" target="_blank">www.sbrac.org</a><span class="">


_______________________________________________
USRP-users mailing list
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>


</span></pre>
            </blockquote>
            <pre><span class="">

--
Peter Witkowski
<a href="mailto:pwitkowski@gmail.com" target="_blank">pwitkowski@gmail.com</a>


______________________________</span>_________________
USRP-users mailing <a href="mailto:listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>



</pre>
          </blockquote>
          <pre><span class="">

--
Peter Witkowski
<a href="mailto:pwitkowski@gmail.com" target="_blank">pwitkowski@gmail.com</a>


______________________________</span>_________________
USRP-users mailing <a href="mailto:listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><span class="">



_______________________________________________
USRP-users mailing list
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>


</span></pre>
        </blockquote>
      </blockquote>
      <pre></pre>
      <br>
      <fieldset></fieldset>
      <br><span class="">
      <pre>_______________________________________________
USRP-users mailing list
<a href="mailto:USRP-users@lists.ettus.com" target="_blank">USRP-users@lists.ettus.com</a>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Peter Witkowski<br><a href="mailto:pwitkowski@gmail.com">pwitkowski@gmail.com</a>
</div></div></div></div></div>