XSDK 2017.1/2017.3 Ubuntu 16.04 problem: ERROR : (XSDB Server)Socket bind error. Cannot assign requested address

[saleksin]

I have problem with XSDK 2017.1 and 2017.3, on Ubuntu 16.04. When I launch XSDK, I get following error on the console:
 ERROR    : (XSDB Server)Socket bind error. Cannot assign requested address
    invoked from within
"::tcf::eval {tcf_sync_eval server_connect}"
    (procedure "::tcf::sync_eval" line 2)
    invoked from within
"::tcf::sync_eval server_connect"
    invoked from within
"puts "XSDB Server URL: [::tcf::sync_eval server_connect]""
    (file "/opt/Xilinx/SDK/2017.1/scripts/xsdb/xsdb/xsdb-server.tcl" line 168)
    invoked from within
"source /opt/Xilinx/SDK/2017.1/scripts/xsdb/xsdb/xsdb-server.tcl"
    (file "<path-to-workspace>/temp_xsdb_launch_script.tcl" line 1)

After some time I get exception about problem with initializing sw repositories.

I saw this topic:

https://forums.xilinx.com/t5/Installation-and-Licensing/Vivado-2016-4-2017-1-SDK-launch-problem/td-p/769150

but setting proxy Active Provider to Direct does not solve my problem.

THe problem is both when I launch XSDK from Vivado, and from console, after sourcing setting64.sh. But I can launch both xsdb and xsct stand alone.

What can be wrong?

[stephenm]

Can you re-install the digilent cable drivers

cd /opt/Xilinx/Vivado/2017.3/data/xicom/cable_drivers/lin64/install_script/install_drivers/

sudo ./install_drivers

[saleksin]

Thank you very much for the response!

I did that, but it didn't help.

[sadanan]

GUI starts XSDB server on a tcp port (a free port is dynamically chosen), and in your case it appears like the tcp port cannot be used.

Can you try to start the server manually from standalone XSDB? You can do it like this.

/opt/Xilinx/SDK/2017.1/bin/xsdb -interactive -eval "set xsdb_idle_timeout -1; source /opt/Xilinx/SDK/2017.1/scripts/xsdb/xsdb/xsdb-server.tcl"

If the server is successfully started, you should see a message like this on the terminal

XSDB Server URL: TCP:localhost:53358

If this doesn't work, you can try to use a hardcoded free port in /opt/Xilinx/SDK/2017.1/scripts/xsdb/xsdb/xsdb-server.tcl

Find ::tcf::server_start tcp:localhost:0 in this script and replace 0 with a free port number

[saleksin · Accepted solution]

Thank you very much for the response.

It turned out, that some time ago I changed my localhost address (in /etc/hosts) to one, that was assigned to virtual machine with web development environment. After I changed it back, it works again.

[philtempblue]

Hello!

I'm having the same problem with 2017.4.  I was able to narrow the problem down some.  It seems that when I have a live network connection, the XSDB server can't start with the localhost TCP port (even when I've hardcoded the port number as suggested).  But if I disconnect the live network connection (unplug Ethernet), then the XSDB can open the localhost TCP port on the hardcoded port number.

Any suggestions as to why this might be the case?

This all started to happen around the same time I installed the PetaLinux 2017.4 build tools (though I cannot isolate that as the cause).  Prior to installing PetaLinux onto this machine, I was building PL successfully on a different machine.  When I decided to put PL build tools on the current machine, I went through the entire list of packages in the "Installation Requirements" of the UG1144 (2017.4).  I'm wondering if updating one of those tools could have caused any of this?  When I try to build a kernel with PL, I get a similar error "Cannot assign requested address" when an xsct command is executed.  Disconnecting my network Ethernet connection seems to be the work around, as that get's me past that error.

Starting to think it's a networking issue: when the localhost "lo" is the only connection, everything is fine.

I'm using Ubuntu 16.04 and Xilinx is installed in: /home/<user>/dev/Xilinx 

UPDATED AND SOLVED:  Well this is embarrassing... using "nslookup localhost" revealed that the DNS server here was resolving "localhost", which was not 127.0.0.1.  So that was the problem and has been fixed.