[USRP-users] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run

[Jerrid Plymale via USRP-users]

Hey All,

So I recently started having issues with the uhd_image_builder_gui after doing 
a fresh install of UHD and GNU Radio with RFNoC. Below is the output of the 
terminal when I try to run the gui. Anyone run into this issue and know how to 
fix it?

Traceback (most recent call last):
  File "./uhd_image_builder_gui.py", line 656, in 
main()
  File "./uhd_image_builder_gui.py", line 652, in main
_window = MainWindow()
  File "./uhd_image_builder_gui.py", line 71, in __init__
self.init_gui()
  File "./uhd_image_builder_gui.py", line 149, in init_gui
self.populate_target('e300')
  File "./uhd_image_builder_gui.py", line 608, in populate_target
with open(build_targets) as fil:
IOError: [Errno 2] No such file or directory: 
'/home/ck/rfnoc/src/uhd-fpga/usrp3/tools/scripts/../../top/e300/Makefile'

Best Regards,

Jerrid
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers

[Cherif Diouf via USRP-users]

Hi Jerrid,



Some hints, for info,  I am working with the X310 device, but you can take the 
big picture.


I previously met  such issues, those were related to signal re-definitions.


The file *rfnoc_ce_auto_inst_x310.v* at lines 19/20 is re-defining the 
ce_clk/ce_rst signals by assigning to them  radio_clk/radio_rst signals. The 
issue here is that ce_clk is a clock of its own and is already defined in the 
top block file *x300.v* at lines 259 and 290. My filepath is 
rfnoc/src/uhd-fpga/usrp3/top/x300/.


Vivado 2017.4 would just let this pass but when I moved to Vivado 2018.4 the 
build would each time fail, popping Net having multiple drivers errors.


Changing the ce_clk/ce_rst signals names in the *rfnoc_ce_auto_inst_x310.v* and 
modifying this instantiation file accordingly will make the build work. The 
solution is ok If you are using a different custom  instantiation file,.


However, I am not sure that in your case it will help, because your 
*rfnoc_ce_auto_inst_x310.v* file is re-created at each build command. So likely 
anything you update in the file will be dumped at the next build.




Best Regards

Cherif


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers

[Brian Padalino via USRP-users]

On Fri, Jan 3, 2020 at 1:14 PM Cherif Diouf via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Jerrid,
>
>
>
> Some hints, for info,  I am working with the X310 device, but you can
> take the big picture.
>
>
> I previously met  such issues, those were related to signal re-definitions.
>
>
> The file *rfnoc_ce_auto_inst_x310.v* at lines 19/20 is re-defining the
> ce_clk/ce_rst signals by assigning to them  radio_clk/radio_rst signals.
> The issue here is that ce_clk is a clock of its own and is already defined
> in the top block file *x300.v* at lines 259 and 290. My filepath is
> rfnoc/src/uhd-fpga/usrp3/top/x300/.
>

In the 3.15.0.0 code on github I don't see what you're talking about:


https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/top/x300/rfnoc_ce_auto_inst_x300.v

Looking at the history of the file, it looked like that might have been
removed way back in 2016 in commit c98bc14fe0ea2c27a5629a24d47915eb7e0b6700.

Jerrid - do you have those lines that Cherif is describing?

Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers

[Cherif Diouf via USRP-users]

I have this version UHD 3.15.0.git-84-g164d76dc

but the lines are there whenever you use the  ./uhd_image_builder.py scripts.

Best Regards
Cherif




From: Brian Padalino 
Sent: Friday, January 3, 2020 7:25:00 PM
To: Cherif Diouf
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC 
MDRV-1] Multiple Driver Nets: Net has multiple drivers

On Fri, Jan 3, 2020 at 1:14 PM Cherif Diouf via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Hi Jerrid,



Some hints, for info,  I am working with the X310 device, but you can take the 
big picture.


I previously met  such issues, those were related to signal re-definitions.


The file *rfnoc_ce_auto_inst_x310.v* at lines 19/20 is re-defining the 
ce_clk/ce_rst signals by assigning to them  radio_clk/radio_rst signals. The 
issue here is that ce_clk is a clock of its own and is already defined in the 
top block file *x300.v* at lines 259 and 290. My filepath is 
rfnoc/src/uhd-fpga/usrp3/top/x300/.

In the 3.15.0.0 code on github I don't see what you're talking about:

  
https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/top/x300/rfnoc_ce_auto_inst_x300.v

Looking at the history of the file, it looked like that might have been removed 
way back in 2016 in commit c98bc14fe0ea2c27a5629a24d47915eb7e0b6700.

Jerrid - do you have those lines that Cherif is describing?

Brian
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Building RFNoC image with default blocks fails, [DRC MDRV-1] Multiple Driver Nets: Net has multiple drivers

[Brian Padalino via USRP-users]

On Fri, Jan 3, 2020 at 1:41 PM Cherif Diouf  wrote:

> I have this version UHD 3.15.0.git-84-g164d76dc
>
> but the lines are there whenever you use the  ./uhd_image_builder.py
> scripts.
>

Ah, I see it now:


https://github.com/EttusResearch/fpga/blob/fde2a94eb7231af859653db8caaf777ae2b66199/usrp3/tools/scripts/uhd_image_builder.py#L44

Someone at Ettus should probably stop assigning those clocks.

Brian

>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run

[Marcus Müller via USRP-users]

Hi Jerrid, 

could you check /home/ck/rfnoc/src/uhd-fpga/usrp3/top/e300/Makefile
exists?
My uhd-fpga directory has that; I think yours *should*. Which version
of the uhd-fpga repo are you using?

Best regards,
Marcus

On Fri, 2020-01-03 at 15:43 +, Jerrid Plymale via USRP-users wrote:
> Hey All,
> 
> So I recently started having issues with the uhd_image_builder_gui
> after doing a fresh install of UHD and GNU Radio with RFNoC. Below is
> the output of the terminal when I try to run the gui. Anyone run into
> this issue and know how to fix it?
> 
> Traceback (most recent call last):
>   File "./uhd_image_builder_gui.py", line 656, in 
> main()
>   File "./uhd_image_builder_gui.py", line 652, in main
> _window = MainWindow()
>   File "./uhd_image_builder_gui.py", line 71, in __init__
> self.init_gui()
>   File "./uhd_image_builder_gui.py", line 149, in init_gui
> self.populate_target('e300')
>   File "./uhd_image_builder_gui.py", line 608, in populate_target
> with open(build_targets) as fil:
> IOError: [Errno 2] No such file or directory:
> '/home/ck/rfnoc/src/uhd-
> fpga/usrp3/tools/scripts/../../top/e300/Makefile'
> 
> Best Regards,
> 
> Jerrid
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run

[Jerrid Plymale via USRP-users]

Hey Marcus,

Thanks for your reply, it reminded me what I needed to do. In the version I am 
running, the e300 folder has been replaced with the e31x folder, so I just 
changed the e300 target to e31x in the uhd_image_builder_gui python file and it 
is working again now. Not sure how to check the version of uhd-fpga repo to 
tell you the truth.

Best Regards, 

Jerrid

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run

[Nate Temple via USRP-users]

There was recently a change to the directory structure for the E300/E310s.

If you're running 3.15.0.0, this should be fixed, see the commits from ~Nov
21 here:

https://github.com/EttusResearch/fpga/commits/v3.15.0.0/usrp3

Regards,
Nate Temple

On Fri, Jan 3, 2020 at 11:17 AM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Jerrid,
>
> could you check /home/ck/rfnoc/src/uhd-fpga/usrp3/top/e300/Makefile
> exists?
> My uhd-fpga directory has that; I think yours *should*. Which version
> of the uhd-fpga repo are you using?
>
> Best regards,
> Marcus
>
> On Fri, 2020-01-03 at 15:43 +, Jerrid Plymale via USRP-users wrote:
> > Hey All,
> >
> > So I recently started having issues with the uhd_image_builder_gui
> > after doing a fresh install of UHD and GNU Radio with RFNoC. Below is
> > the output of the terminal when I try to run the gui. Anyone run into
> > this issue and know how to fix it?
> >
> > Traceback (most recent call last):
> >   File "./uhd_image_builder_gui.py", line 656, in 
> > main()
> >   File "./uhd_image_builder_gui.py", line 652, in main
> > _window = MainWindow()
> >   File "./uhd_image_builder_gui.py", line 71, in __init__
> > self.init_gui()
> >   File "./uhd_image_builder_gui.py", line 149, in init_gui
> > self.populate_target('e300')
> >   File "./uhd_image_builder_gui.py", line 608, in populate_target
> > with open(build_targets) as fil:
> > IOError: [Errno 2] No such file or directory:
> > '/home/ck/rfnoc/src/uhd-
> > fpga/usrp3/tools/scripts/../../top/e300/Makefile'
> >
> > Best Regards,
> >
> > Jerrid
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run

[Marcus Müller via USRP-users]

Ah, wonderful :)

that should be a git repository, so `git describe` typically delivers a
string that is "last tag on the current branch - commits since then -
gCommit Hash", typically.

Best regards,
Marcus

On Fri, 2020-01-03 at 19:27 +, Jerrid Plymale wrote:
> Hey Marcus,
> 
> Thanks for your reply, it reminded me what I needed to do. In the
> version I am running, the e300 folder has been replaced with the e31x
> folder, so I just changed the e300 target to e31x in the
> uhd_image_builder_gui python file and it is working again now. Not
> sure how to check the version of uhd-fpga repo to tell you the truth.
> 
> Best Regards, 
> 
> Jerrid
> 


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GPIO Example Failure on N310

[Sam Reiter via USRP-users]

Hey Jeff,

Could you give this a shot on 3.15.0.0 and let me know the results? Based
on that output, the issue looks confined to ATR but it's not something I've
seen reported up to this point.

If 3.15.0.0 shows this issue as well, I'll reproduce it on my end and get a
bug filed.

Sam Reiter
Ettus Research

On Fri, Dec 20, 2019 at 10:19 AM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I built the UHD example, gpio.cpp (no modifications), and ran it on my
> N310 to start experimenting with the GPIO.  It returned with two failures:
>
> Testing ATR TX output...fail:
> Bit 2 should be set, but is not
>Bit  10  9  8  7  6  5  4  3  2  1  0
>   CTRL:  0  0  0  0  0  0  0  1  1  1  1
>DDR:  0  0  0  0  0  0  1  1  1  1  1
> ATR_0X:  0  0  0  0  0  0  0  0  0  0  1
> ATR_RX:  0  0  0  0  0  0  0  0  0  1  0
> ATR_TX:  0  0  0  0  0  0  0  0  1  0  0
> ATR_XX:  0  0  0  0  0  0  0  1  0  0  0
>OUT:  0  0  0  0  0  0  0  0  0  0  0
>   READBACK:  1  1  1  1  1  1  0  0  0  0  1
>
> Testing ATR full duplex output...fail:
> Bit 3 should be set, but is not
>Bit  10  9  8  7  6  5  4  3  2  1  0
>   CTRL:  0  0  0  0  0  0  0  1  1  1  1
>DDR:  0  0  0  0  0  0  1  1  1  1  1
> ATR_0X:  0  0  0  0  0  0  0  0  0  0  1
> ATR_RX:  0  0  0  0  0  0  0  0  0  1  0
> ATR_TX:  0  0  0  0  0  0  0  0  1  0  0
> ATR_XX:  0  0  0  0  0  0  0  1  0  0  0
>OUT:  0  0  0  0  0  0  0  0  0  0  0
>   READBACK:  1  1  1  1  1  1  0  0  0  0  1
>
> 2 tests failed
>
> Done!
>
>
> Is this something that I should be concerned about?
>
> If I compile and run the same example with my X310, everything passes.
>
> Here's the uhd_config_info --print-all from my N310:
>
> UHD 3.14.1.1-0-g0347a6d8
> Build date: Thu, 26 Sep 2019 01:26:32
> C compiler: GNU 7.3.0
> C++ compiler: GNU 7.3.0
> C flags: -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 -DUHD_LOG_CONSOLE_LEVEL=2
> -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR -DHAVE_LIBER
> IO -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
>  --sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon
> -oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot  -O2 -pipe -g
> -feliminate-unused-debug-types -fdebug-prefix-map=/home/oe-builder/bu
> ild/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1=/usr/src/debug/uhd/3.14.1.1-r1
> -fdebug-prefix-map=/home/oe-build
> er/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot=
> -fdebug-prefix-map=/home/oe-builder/build/t
> mp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot-native=
>   -march=armv7-a -marm -mfpu=neon -mfloat-abi=
> hard -mcpu=cortex-a9
>  
> --sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroo
> t
> C++ flags: -DHAVE_CONFIG_H -DUHD_LOG_MIN_LEVEL=1 -DUHD_LOG_CONSOLE_LEVEL=2
> -DUHD_LOG_FILE_LEVEL=2 -DUHD_LOG_CONSOLE_COLOR -DHAVE_LIB
> ERIO -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
>  --sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-ne
> on-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot  -O2 -pipe -g
> -feliminate-unused-debug-types -fdebug-prefix-map=/home/oe-builder/
> build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1=/usr/src/debug/uhd/3.14.1.1-r1
> -fdebug-prefix-map=/home/oe-bui
> lder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot=
> -fdebug-prefix-map=/home/oe-builder/build
> /tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/uhd/3.14.1.1-r1/recipe-sysroot-native=
>  -fvisibility-inlines-hidden  -march=armv7-a
>  -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9
>  
> --sysroot=/home/oe-builder/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi
> /uhd/3.14.1.1-r1/recipe-sysroot -fvisibility=hidden
> -fvisibility-inlines-hidden
> Enabled components: LibUHD, LibUHD - C API, Examples, Utils, Tests,
> LIBERIO, USB, GPSD, MPMD, N300, N320, E320
> Install prefix: /usr
> Boost version: 1.66
> Libusb version: 1.0.23
> Package path: /usr
> Images directory: /usr/share/uhd/images
> ABI version string: 3.14.1
>
> Thanks,
> Jeff
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Cannot update FPGA image on USRP E320

[Sam Reiter via USRP-users]

Hey Subu,

I'd suspect that the MPM versioning is the issue here. You can manually
compile and install MPM on your E320, or you can simply reflash your SD
card with the latest SDimg. Based on when this was posted vs when v3.15.0.0
was tagged, I'd guess you're working with a release candidate and didn't
have access to a fresh filesystem image to install. You'll want to install
v3.15.0.0 on your host first, then follow this guide for the mender update:

https://kb.ettus.com/E320_Getting_Started_Guide#Mender_Update_Process

Or this guide for reflashing the SD card by physically inserting it into
your PC (you need to take the backplate off the E320 to access the SD):

https://kb.ettus.com/Writing_the_USRP_File_System_Disk_Image_to_a_SD_Card

Sam Reiter
Ettus Research

On Tue, Dec 24, 2019 at 12:15 PM Subu Rama via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am going to run my USRP E320 in host mode. To make sure that the FPGA
> images on my development host and E320 match, I am trying to upload 1G FPGA
> image to the E320.
>
> The following is the process I am following:
>
> Network interfaces on the E320:
>
> root@ni-e320-31BB638:~# ip a
> 1: lo:  mtu 65536 qdisc noqueue qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast qlen
> 1000
> link/ether 00:80:2f:28:8d:7e brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
>valid_lft forever preferred_lft forever
> 3: sfp0:  mtu 1500 qdisc pfifo_fast qlen
> 1000
> link/ether 00:80:2f:28:8d:7f brd ff:ff:ff:ff:ff:ff
> inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
>valid_lft forever preferred_lft forever
>
> --
> Trying to upload the 1G image to the E320:
>
> gnuradio@nuc-qrc3 (UHD-3.15.LTS):/usr/local/src/uhd/fpga-src >>
> uhd_image_loader --args
> "type=e3xx,product=e320,mgmt_addr=192.168.1.2,fpga=1G"
> [INFO] [UHD] linux; GNU C++ version 9.2.1 20191008; Boost_107100;
> UHD_3.15.0.0-0-g4e06022c
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.1.2,type=e3xx,product=e320,serial=31BB638,claimed=False,skip_init=1
> [INFO] [MPMD] Claimed device without full initialization.
> [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
> [INFO] [MPM.PeriphManager] Updating component `fpga'
> [INFO] [MPM.PeriphManager] Updating component `dts'
> [ERROR] [MPM.PeriphManager] Error executing `dtc': Command '['dtc',
> '--symbols', '-O', 'dtb', '-q', '-o', '/lib/firmware/e320.dtbo',
> '/lib/firmware/e320.dts']' returned non-zero exit status 1
> [INFO] [MPM.RPCServer] Resetting peripheral manager.
> [INFO] [MPM.PeriphManager] Device serial number: 31BB638
> [INFO] [MPMD IMAGE LOADER] Update component function succeeded.
> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
> [WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected compat
> for component `FPGA'. Expected: 3.0 Actual: 3.1
>
> ---
> Result of a probe:
>
> gnuradio@nuc-qrc3 (UHD-3.15.LTS):/usr/local/src/uhd/fpga-src >>
> uhd_usrp_probe --args "addr=192.168.10.2"
> [INFO] [UHD] linux; GNU C++ version 9.2.1 20191008; Boost_107100;
> UHD_3.15.0.0-0-g4e06022c
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.2,type=e3xx,product=e320,serial=31BB638,claimed=False,addr=192.168.10.2
> [INFO] [MPM.main] Launching USRP/MPM, version: 3.13.0.2-gunknown
> [INFO] [MPM.main] Spawning RPC process...
> [INFO] [MPM.PeriphManager] Device serial number: 31BB638
> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
> [WARNING] [MPM.PeriphManager] Actual minor compat ahead of expected compat
> for component `FPGA'. Expected: 3.0 Actual: 3.1
> [INFO] [MPM.RPCServer] RPC server ready!
> [INFO] [MPM.RPCServer] Spawning watchdog task...
> [WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
> 1.25e+08
> [WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
> 1.25e+08
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=e320,mgmt_addr=192.168.10.2'.
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1329 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
> [WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
> 1.25e+08
> [WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
> 1.25e+08
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
> [WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
> 1.25e+08
> [WARNING] [MPMD] Could not determine link speed; using 1GibE max speed of
> 1.25e+08
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [WARNING] [MPMD] Could not determine link speed; using 1GibE max

Re: [USRP-users] DPDK runtime error

[Sam Reiter via USRP-users]

Florian,

DPDK 18.11 is not supported on UHD 3.x. You'll need to use DPDK 17.11.

Sam Reiter
Ettus Research

On Mon, Dec 23, 2019 at 9:51 AM Florian Kaltenberger via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
>
> we have finally managed to set up UHD (3.15) with DPDK (18.11) support on
> our RedHat 7 system (both installed from source) with our N310. I have
> configured the system as explained here
> http://files.ettus.com/manual/page_dpdk.html but when calling
>
> uhd_usrp_probe --args
> "use_dpdk=1,mgmt_addr=192.168.12.1,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=122.88e6,type=n3xx"
>
> I am getting the following runtime error (all the way at the bottom):
> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-39);
> Boost_106900; UHD_3.15.0.0-0-g4e06022c
> EAL: Detected 10 lcore(s)
> EAL: No free hugepages reported in hugepages-1048576kB
> EAL: Probing VFIO support...
> EAL: VFIO support initialized
> EAL: PCI device :00:19.0 on NUMA socket 0
> EAL:   probe driver: 8086:153a net_e1000_em
> EAL: PCI device :01:00.0 on NUMA socket 0
> EAL:   probe driver: 8086:1572 net_i40e
> EAL: PCI device :01:00.1 on NUMA socket 0
> EAL:   probe driver: 8086:1572 net_i40e
> EAL:   using IOMMU type 1 (Type 1)
> PMD: Global register is changed during enable FDIR flexible payload
> PMD: Global register is changed during support QinQ parser
> PMD: Global register is changed during configure hash input set
> PMD: Global register is changed during configure fdir mask
> PMD: Global register is changed during configure hash mask
> PMD: Global register is changed during support QinQ cloud filter
> PMD: Global register is changed during support TPID configuration
> EAL: PCI device :01:00.2 on NUMA socket 0
> EAL:   probe driver: 8086:1572 net_i40e
> EAL: PCI device :01:00.3 on NUMA socket 0
> EAL:   probe driver: 8086:1572 net_i40e
> PMD: Global register is changed during enable FDIR flexible payload
> PMD: Global register is changed during support QinQ parser
> PMD: Global register is changed during configure hash input set
> PMD: Global register is changed during configure fdir mask
> PMD: Global register is changed during configure hash mask
> PMD: Global register is changed during support QinQ cloud filter
> PMD: Global register is changed during support TPID configuration
> EAL: Waiting for links to come up...
> EAL: Init DONE!
> EAL: Starting I/O threads!
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.12.1,type=n3xx,product=n310,serial=31641BC,claimed=False,use_dpdk=1,addr=192.168.10.2,second_addr=192.168.20.2,master_clock_rate=122.88e6
> [INFO] [MPM.PeriphManager] init() called with device args
> `mgmt_addr=192.168.12.1,product=n310,master_clock_rate=122.88e6,second_addr=192.168.20.2,use_dpdk=1,clock_source=internal,time_source=internal'.
> EAL: Please set IPv4 address for port 0 before opening socket
> [ERROR] [MPMD] Failure during block enumeration: AssertionError: _rx_sock
> != nullptr
>   in uhd::transport::dpdk_zero_copy_impl::dpdk_zero_copy_impl(const
> uhd::transport::uhd_dpdk_ctx&, unsigned int, const string&, const string&,
> const string&, const uhd::transport::zero_copy_xport_params&)
>
> I am also copying the output of "dpdk-devbind  --status" which shows that
> the two interfaces connected to the USRP use the vfio-pci driver for DPDK
>
> Network devices using DPDK-compatible driver
> 
> :01:00.1 'Ethernet Controller X710 for 10GbE SFP+ 1572' drv=vfio-pci
> unused=i40e
> :01:00.3 'Ethernet Controller X710 for 10GbE SFP+ 1572' drv=vfio-pci
> unused=i40e
>
> Network devices using kernel driver
> ===
> :00:19.0 'Ethernet Connection I217-LM 153a' if=enp0s25 drv=e1000e
> unused=vfio-pci *Active*
> :01:00.0 'Ethernet Controller X710 for 10GbE SFP+ 1572' if=p1p1
> drv=i40e unused=vfio-pci
> :01:00.2 'Ethernet Controller X710 for 10GbE SFP+ 1572' if=p1p3
> drv=i40e unused=vfio-pci
>
> What surprises me is that in the output of the uhd_usrp_probe, it does not
> say it is using the driver for DPDK. any ideas what could be wrong?
>
> Florian.
> --
> Follow us on Google+ ,
> LinkedIn , or Twitter
> !
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] TwinRX RX1 LO1 occasionally at wrong frequency

[Sam Reiter via USRP-users]

Daniel,

This is tricky. Not only have I never seen this issue, but it sounds like
it happens intermittently for you as well. If this is something you're
still running into, I'd encourage you to email me at supp...@ettus.com
directly. We can cover some additional troubleshooting and potentially get
these boards sent in examination, if necessary.

Best,

Sam Reiter
Ettus Research

On Thu, Nov 7, 2019 at 12:51 PM Neunteufel, Daniel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
>
> I’m using two X310, each with two TwinRX daughterboards, connected to a
> host via two 10Gbit SFP+ links per X310. The host machine runs UHD 3.14.1.1
> using DPDK on ubuntu 18.04.
>
>
> When applying a CW (2.44 GHz) signal at the input of all 8 ports and
> running rx_samples_to_file for all channels, occasionally, the obtained IQ
> data does not contain the applied signal. This happens randomly, in about
> 50 % of the cases, only on the TwinRX RX1 channels and only on three out
> of four TwinRX daughterboards.
>
>
> I tried to debug the problem and it turns out that in those cases the LO1
> of the affected channels cannot be observed at 3.69 GHz as expected, but
> rather around 3.25 GHz.
>
> The UHD API, however, claims that everything is in best order when reading
> back the LO values. Inserting delays after setting the frequency values as
> recommended does not help, either.
> All LO sources are set to "internal".
>
>
> Any ideas what could be the issue here? Thanks!
>
>
> Regards,
> Daniel
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com