Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Louis Brown via USRP-users]

I built from a fresh clone with the normal:



git clone https://github.com/EttusResearch/uhd

cd uhd/host/
mkdir build

cd build

cmake ../

make -j8

make test

sudo make install

sudo ldconfig



Then rebuilt gnuradio after that since they said the ABI changed.


Lou




On May 11, 2018, at 09:43 PM, switchlanez  wrote:


Yes, I did:
git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git



and the "what():  map::at" error is reproduced when I use that branch. So then 
I checked out the uhd maint head like you but can't build it properly. What branch of 
gr-ettus are you using? Did you install it after installing the uhd maint head?


Note: I ran into similar gr-ettus build issues when I checked out the uhd maint 
branch commit Michael mentioned earlier. My workaround for that was to instead 
the uhd rfnoc-devel branch head then modify the radio_ctrl_impl.hpp and 
radio_ctrl_impl.cpp files to match what was checked into uhd maint branch 
(commit 8922095). So I never actually got uhd maint branch to build with with 
gr-ettus master branch.



On Fri, May 11, 2018 at 7:21 PM, Louis Brown  wrote:



Did you “git clone — recursive” then switch to the rfnoc branch?  I’m not using 
the rfnoc branch; just the normal maintenance branch, but last time I messed 
with it, you had to do that.

On May 11, 2018, at 21:16, switchlanez  wrote:


Wow good to know, Lou.

I checked out the head of the uhd maint branch (commit 34c5610) and installed it (set 
"ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I install the head of 
gr-ettus master branch (commit 4ef12d) I get an error:

/home/switchlanez/rfnoc_2017.4/src/gr-ettus/lib/rfnoc_fir_cci_impl.cc:26:40: 
fatal error: uhd/rfnoc/fir_block_ctrl.hpp: No such file or directory
compilation terminated.
lib/CMakeFiles/gnuradio-ettus.dir/build.make:120: recipe for target 
'lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs
[ 46%] Built target ettus_swig_swig_2d0df
Scanning dependencies of target pygen_swig_5fc0a
[ 48%] Generating ettus_swig.pyo
[ 51%] Generating ettus_swig.pyc
[ 53%] Built target pygen_swig_5fc0a
CMakeFiles/Makefile2:139: recipe for target 
'lib/CMakeFiles/gnuradio-ettus.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2


I am probably building it wrong. Does anybody know the correct way?


Andrew



On Fri, May 11, 2018 at 5:48 PM, Louis Brown  wrote:



Tried the X310 today on the maintenance branch, and the TX light illuminates, 
but did not check for proper quadrature output.  Will check it tomorrow.  Was 
able to do 100 Msps full duplex.


Lou



On May 11, 2018, at 19:18, switchlanez  wrote:


Thanks, Michael.



So with the fix you referenced RFNoC: Radio now works in Rx mode but does not seem to work work in 
Tx mode regardless of what's connected to its input (I've tried GNU Radio's in-tree Signal Source 
then Null Source blocks separately). The  "what():  map::at" error is resolved so there 
is no error message but the "TX/RX" indicator light on the X310 front panel fails to 
light up. Has that been fixed or is a fix in progress?



On Mon, May 7, 2018 at 9:12 AM, Michael West  wrote:

Hi Andrew,


First, maint was just updated with the fix for the LFTX and LFRX boards on X3x0.


Second, yes, you can install multiple installations of UHD by setting the 
CMAKE_INSTALL_PREFIX different for each installation.  You will have to set the 
PATH and LD_LIBRARY_PATH environment variables appropriately to switch between 
them.


Regards,

Michael



On Fri, May 4, 2018 at 11:43 AM, switchlanez  wrote:

Thanks Michael. Do you know if I were to install rfnoc under a different prefix 
would the UHD version be able to be switched between the prefixes? I'm using an 
older rfnoc build compatible with Vivado 2015.4 and hesitant to install the 
latest build and checkout that new fix if it it will overwrite the older UHD 
version.



On Fri, May 4, 2018 at 11:25 AM, Michael West  wrote:

Hi Andrew,


The fix is on the master branch (commit 8922095).  It is being included in the 
next set of commits on the maint branch that should be available in the next 
few days.


Regards,

Michael



On Wed, May 2, 2018 at 1:13 PM, switchlanez  wrote:

Hi Michael,


I see new commits have been entered in the uhd maint branch in the last couple 
days. Were any related to this issue?


Andrew



On Mon, Apr 23, 2018 at 11:12 AM, Michael West  wrote:

Hi Louis/Andrew,


The root cause of the issue has been identified and a fix is in progress.  We 
should have the fix available on the head of the maint 

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Louis Brown via USRP-users]

Did you “git clone — recursive” then switch to the rfnoc branch?  I’m not using 
the rfnoc branch; just the normal maintenance branch, but last time I messed 
with it, you had to do that.

> On May 11, 2018, at 21:16, switchlanez  wrote:
> 
> Wow good to know, Lou.
> 
> I checked out the head of the uhd maint branch (commit 34c5610) and installed 
> it (set "ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I install the 
> head of gr-ettus master branch (commit 4ef12d) I get an error:
> 
> /home/switchlanez/rfnoc_2017.4/src/gr-ettus/lib/rfnoc_fir_cci_impl.cc:26:40: 
> fatal error: uhd/rfnoc/fir_block_ctrl.hpp: No such file or directory
> compilation terminated.
> lib/CMakeFiles/gnuradio-ettus.dir/build.make:120: recipe for target 
> 'lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o] 
> Error 1
> make[2]: *** Waiting for unfinished jobs
> [ 46%] Built target ettus_swig_swig_2d0df
> Scanning dependencies of target pygen_swig_5fc0a
> [ 48%] Generating ettus_swig.pyo
> [ 51%] Generating ettus_swig.pyc
> [ 53%] Built target pygen_swig_5fc0a
> CMakeFiles/Makefile2:139: recipe for target 
> 'lib/CMakeFiles/gnuradio-ettus.dir/all' failed
> make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> I am probably building it wrong. Does anybody know the correct way?
> 
> Andrew
> 
>> On Fri, May 11, 2018 at 5:48 PM, Louis Brown  wrote:
>> Tried the X310 today on the maintenance branch, and the TX light 
>> illuminates, but did not check for proper quadrature output.  Will check it 
>> tomorrow.  Was able to do 100 Msps full duplex.
>> 
>> Lou
>> 
>> 
>>> On May 11, 2018, at 19:18, switchlanez  wrote:
>>> 
>>> Thanks, Michael.
>>> 
>>> So with the fix you referenced RFNoC: Radio now works in Rx mode but does 
>>> not seem to work work in Tx mode regardless of what's connected to its 
>>> input (I've tried GNU Radio's in-tree Signal Source then Null Source blocks 
>>> separately). The  "what():  map::at" error is resolved so there is no error 
>>> message but the "TX/RX" indicator light on the X310 front panel fails to 
>>> light up. Has that been fixed or is a fix in progress?
>>> 
 On Mon, May 7, 2018 at 9:12 AM, Michael West  
 wrote:
 Hi Andrew,
 
 First, maint was just updated with the fix for the LFTX and LFRX boards on 
 X3x0.
 
 Second, yes, you can install multiple installations of UHD by setting the 
 CMAKE_INSTALL_PREFIX different for each installation.  You will have to 
 set the PATH and LD_LIBRARY_PATH environment variables appropriately to 
 switch between them.
 
 Regards,
 Michael
 
> On Fri, May 4, 2018 at 11:43 AM, switchlanez  
> wrote:
> Thanks Michael. Do you know if I were to install rfnoc under a different 
> prefix would the UHD version be able to be switched between the prefixes? 
> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant 
> to install the latest build and checkout that new fix if it it will 
> overwrite the older UHD version.
> 
>> On Fri, May 4, 2018 at 11:25 AM, Michael West  
>> wrote:
>> Hi Andrew,
>> 
>> The fix is on the master branch (commit 8922095).  It is being included 
>> in the next set of commits on the maint branch that should be available 
>> in the next few days.
>> 
>> Regards,
>> Michael
>> 
>>> On Wed, May 2, 2018 at 1:13 PM, switchlanez  
>>> wrote:
>>> Hi Michael,
>>> 
>>> I see new commits have been entered in the uhd maint branch in the last 
>>> couple days. Were any related to this issue?
>>> 
>>> Andrew
>>> 
 On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
  wrote:
 Hi Louis/Andrew,
 
 The root cause of the issue has been identified and a fix is in 
 progress.  We should have the fix available on the head of the maint 
 branch very soon.  Thank you for bringing it to our attention!
 
 Regards,
 Michael
 
> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users 
>  wrote:
> I have an issue that may be related. Using LFTX and LFRX boards in an 
> X310, anytime I use the RFNoC Radio block in Rx mode the run 
> terminates with:
> 
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  map::at
> 
> Following for updates.
> 
> Andrew
> 
> 
>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users 
>>  wrote:

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[switchlanez via USRP-users]

Wow good to know, Lou.

I checked out the head of the uhd maint branch (commit 34c5610
)
and installed it (set "ENABLE_RFNOC" to "ON" in CMakeLists.txt). Now when I
install the head of gr-ettus master branch (commit 4ef12d
)
I get an error:

/home/switchlanez/rfnoc_2017.4/src/gr-ettus/lib/rfnoc_fir_cci_impl.cc:26:40:
fatal error: uhd/rfnoc/fir_block_ctrl.hpp: No such file or directory
compilation terminated.
lib/CMakeFiles/gnuradio-ettus.dir/build.make:120: recipe for target
'lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-ettus.dir/rfnoc_fir_cci_impl.cc.o]
Error 1
make[2]: *** Waiting for unfinished jobs
[ 46%] Built target ettus_swig_swig_2d0df
Scanning dependencies of target pygen_swig_5fc0a
[ 48%] Generating ettus_swig.pyo
[ 51%] Generating ettus_swig.pyc
[ 53%] Built target pygen_swig_5fc0a
CMakeFiles/Makefile2:139: recipe for target
'lib/CMakeFiles/gnuradio-ettus.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-ettus.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

I am probably building it wrong. Does anybody know the correct way?

Andrew

On Fri, May 11, 2018 at 5:48 PM, Louis Brown  wrote:

> Tried the X310 today on the maintenance branch, and the TX light
> illuminates, but did not check for proper quadrature output.  Will check it
> tomorrow.  Was able to do 100 Msps full duplex.
>
> Lou
>
>
> On May 11, 2018, at 19:18, switchlanez  wrote:
>
> Thanks, Michael.
>
> So with the fix you referenced RFNoC: Radio now works in Rx mode but does
> not seem to work work in Tx mode regardless of what's connected to its
> input (I've tried GNU Radio's in-tree Signal Source then Null Source blocks
> separately). The  "what():  map::at" error is resolved so there is no
> error message but the "TX/RX" indicator light on the X310 front panel fails
> to light up. Has that been fixed or is a fix in progress?
>
> On Mon, May 7, 2018 at 9:12 AM, Michael West 
> wrote:
>
>> Hi Andrew,
>>
>> First, maint was just updated with the fix for the LFTX and LFRX boards
>> on X3x0.
>>
>> Second, yes, you can install multiple installations of UHD by setting the
>> CMAKE_INSTALL_PREFIX different for each installation.  You will have to set
>> the PATH and LD_LIBRARY_PATH environment variables appropriately to switch
>> between them.
>>
>> Regards,
>> Michael
>>
>> On Fri, May 4, 2018 at 11:43 AM, switchlanez 
>> wrote:
>>
>>> Thanks Michael. Do you know if I were to install rfnoc under a different
>>> prefix would the UHD version be able to be switched between the prefixes?
>>> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant
>>> to install the latest build and checkout that new fix if it it will
>>> overwrite the older UHD version.
>>>
>>> On Fri, May 4, 2018 at 11:25 AM, Michael West 
>>> wrote:
>>>
 Hi Andrew,

 The fix is on the master branch (commit 8922095
 ).
 It is being included in the next set of commits on the maint branch that
 should be available in the next few days.

 Regards,
 Michael

 On Wed, May 2, 2018 at 1:13 PM, switchlanez 
 wrote:

> Hi Michael,
>
> I see new commits have been entered in the uhd maint branch in the
> last couple days. Were any related to this issue?
>
> Andrew
>
> On Mon, Apr 23, 2018 at 11:12 AM, Michael West  > wrote:
>
>> Hi Louis/Andrew,
>>
>> The root cause of the issue has been identified and a fix is in
>> progress.  We should have the fix available on the head of the maint 
>> branch
>> very soon.  Thank you for bringing it to our attention!
>>
>> Regards,
>> Michael
>>
>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I have an issue that may be related. Using LFTX and LFRX boards in
>>> an X310, anytime I use the RFNoC Radio block in Rx mode the run 
>>> terminates
>>> with:
>>>
>>> terminate called after throwing an instance of 'std::out_of_range'
>>>   what():  map::at
>>>
>>> Following for updates.
>>>
>>> Andrew
>>>
>>>
>>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello Louis:

 Thanks for the detailed feedback. We have reproduced this issue,
 and are debugging it now. We will get back to you and post an update
 shortly.

 --​Neel Pandeya

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Louis Brown via USRP-users]

Tried the X310 today on the maintenance branch, and the TX light illuminates, 
but did not check for proper quadrature output.  Will check it tomorrow.  Was 
able to do 100 Msps full duplex.

Lou


> On May 11, 2018, at 19:18, switchlanez  wrote:
> 
> Thanks, Michael.
> 
> So with the fix you referenced RFNoC: Radio now works in Rx mode but does not 
> seem to work work in Tx mode regardless of what's connected to its input 
> (I've tried GNU Radio's in-tree Signal Source then Null Source blocks 
> separately). The  "what():  map::at" error is resolved so there is no error 
> message but the "TX/RX" indicator light on the X310 front panel fails to 
> light up. Has that been fixed or is a fix in progress?
> 
>> On Mon, May 7, 2018 at 9:12 AM, Michael West  wrote:
>> Hi Andrew,
>> 
>> First, maint was just updated with the fix for the LFTX and LFRX boards on 
>> X3x0.
>> 
>> Second, yes, you can install multiple installations of UHD by setting the 
>> CMAKE_INSTALL_PREFIX different for each installation.  You will have to set 
>> the PATH and LD_LIBRARY_PATH environment variables appropriately to switch 
>> between them.
>> 
>> Regards,
>> Michael
>> 
>>> On Fri, May 4, 2018 at 11:43 AM, switchlanez  wrote:
>>> Thanks Michael. Do you know if I were to install rfnoc under a different 
>>> prefix would the UHD version be able to be switched between the prefixes? 
>>> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant 
>>> to install the latest build and checkout that new fix if it it will 
>>> overwrite the older UHD version.
>>> 
 On Fri, May 4, 2018 at 11:25 AM, Michael West  
 wrote:
 Hi Andrew,
 
 The fix is on the master branch (commit 8922095).  It is being included in 
 the next set of commits on the maint branch that should be available in 
 the next few days.
 
 Regards,
 Michael
 
> On Wed, May 2, 2018 at 1:13 PM, switchlanez  wrote:
> Hi Michael,
> 
> I see new commits have been entered in the uhd maint branch in the last 
> couple days. Were any related to this issue?
> 
> Andrew
> 
>> On Mon, Apr 23, 2018 at 11:12 AM, Michael West  
>> wrote:
>> Hi Louis/Andrew,
>> 
>> The root cause of the issue has been identified and a fix is in 
>> progress.  We should have the fix available on the head of the maint 
>> branch very soon.  Thank you for bringing it to our attention!
>> 
>> Regards,
>> Michael
>> 
>>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users 
>>>  wrote:
>>> I have an issue that may be related. Using LFTX and LFRX boards in an 
>>> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates 
>>> with:
>>> 
>>> terminate called after throwing an instance of 'std::out_of_range'
>>>   what():  map::at
>>> 
>>> Following for updates.
>>> 
>>> Andrew
>>> 
>>> 
 On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users 
  wrote:
 Hello Louis:
 
 Thanks for the detailed feedback. We have reproduced this issue, and 
 are debugging it now. We will get back to you and post an update 
 shortly.
 
 --​Neel Pandeya
 
 
 
 
> On 12 April 2018 at 18:46, Louis Brown via USRP-users 
>  wrote:
> Could it be something to do with this commit for address offsets?
> 
> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2064b0dc6fbcc04c2ded94b4a
> 
> Lou
> 
> 
>> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>> 
>> 
>> Did something change with respect to daughter board addressing in 
>> UHD 3.11?
>> I have an X310 with LFTX and LFRX  in motherboard slot A.
>> When I run benchmark_rate it core dumps as follows:
>> 
>> /*
>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args 
>> "addr=192.168.40.2" --tx_rate=10E6
>> 
>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 
>> 7.3.1-5); Boost_106400; UHD_3.11.0.1-0-unknown
>> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Determining maximum frame size... 
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> [INFO] [X300] Setup basic communication...
>> [INFO] [X300] Loading values from EEPROM...
>> [INFO] [X300] Setup RF frontend clocking...
>> [INFO] [X300] Radio 1x clock:200
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0... 
>> 

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[switchlanez via USRP-users]

Thanks, Michael.

So with the fix you referenced RFNoC: Radio now works in Rx mode but does
not seem to work work in Tx mode regardless of what's connected to its
input (I've tried GNU Radio's in-tree Signal Source then Null Source blocks
separately). The  "what():  map::at" error is resolved so there is no error
message but the "TX/RX" indicator light on the X310 front panel fails to
light up. Has that been fixed or is a fix in progress?

On Mon, May 7, 2018 at 9:12 AM, Michael West  wrote:

> Hi Andrew,
>
> First, maint was just updated with the fix for the LFTX and LFRX boards on
> X3x0.
>
> Second, yes, you can install multiple installations of UHD by setting the
> CMAKE_INSTALL_PREFIX different for each installation.  You will have to set
> the PATH and LD_LIBRARY_PATH environment variables appropriately to switch
> between them.
>
> Regards,
> Michael
>
> On Fri, May 4, 2018 at 11:43 AM, switchlanez 
> wrote:
>
>> Thanks Michael. Do you know if I were to install rfnoc under a different
>> prefix would the UHD version be able to be switched between the prefixes?
>> I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant
>> to install the latest build and checkout that new fix if it it will
>> overwrite the older UHD version.
>>
>> On Fri, May 4, 2018 at 11:25 AM, Michael West 
>> wrote:
>>
>>> Hi Andrew,
>>>
>>> The fix is on the master branch (commit 8922095
>>> ).
>>> It is being included in the next set of commits on the maint branch that
>>> should be available in the next few days.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Wed, May 2, 2018 at 1:13 PM, switchlanez 
>>> wrote:
>>>
 Hi Michael,

 I see new commits have been entered in the uhd maint branch in the last
 couple days. Were any related to this issue?

 Andrew

 On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
 wrote:

> Hi Louis/Andrew,
>
> The root cause of the issue has been identified and a fix is in
> progress.  We should have the fix available on the head of the maint 
> branch
> very soon.  Thank you for bringing it to our attention!
>
> Regards,
> Michael
>
> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I have an issue that may be related. Using LFTX and LFRX boards in an
>> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
>> with:
>>
>> terminate called after throwing an instance of 'std::out_of_range'
>>   what():  map::at
>>
>> Following for updates.
>>
>> Andrew
>>
>>
>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello Louis:
>>>
>>> Thanks for the detailed feedback. We have reproduced this issue, and
>>> are debugging it now. We will get back to you and post an update 
>>> shortly.
>>>
>>> --​Neel Pandeya
>>>
>>>
>>>
>>>
>>> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Could it be something to do with this commit for address offsets?

 https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
 064b0dc6fbcc04c2ded94b4a

 Lou


 On Apr 12, 2018, at 16:38, Louis Brown  wrote:


 Did something change with respect to daughter board addressing in
 UHD 3.11?
 I have an X310 with LFTX and LFRX  in motherboard slot A.
 When I run benchmark_rate it core dumps as follows:

 /*
 [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
 "addr=192.168.40.2" --tx_rate=10E6

 [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat
 7.3.1-5); Boost_106400; UHD_3.11.0.1-0-unknown
 [00:00:00.06] Creating the usrp device with:
 addr=192.168.40.2...
 [INFO] [X300] X300 initialization sequence...
 [INFO] [X300] Determining maximum frame size...
 [INFO] [X300] Maximum frame size: 8000 bytes.
 [INFO] [X300] Setup basic communication...
 [INFO] [X300] Loading values from EEPROM...
 [INFO] [X300] Setup RF frontend clocking...
 [INFO] [X300] Radio 1x clock:200
 [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
 [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
 [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
 [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
 [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1
 input ports
 [INFO] [RFNOC RADIO] Register loopback test 

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[switchlanez via USRP-users]

Thanks Michael. Do you know if I were to install rfnoc under a different
prefix would the UHD version be able to be switched between the prefixes?
I'm using an older rfnoc build compatible with Vivado 2015.4 and hesitant
to install the latest build and checkout that new fix if it it will
overwrite the older UHD version.

On Fri, May 4, 2018 at 11:25 AM, Michael West 
wrote:

> Hi Andrew,
>
> The fix is on the master branch (commit 8922095
> ).
> It is being included in the next set of commits on the maint branch that
> should be available in the next few days.
>
> Regards,
> Michael
>
> On Wed, May 2, 2018 at 1:13 PM, switchlanez  wrote:
>
>> Hi Michael,
>>
>> I see new commits have been entered in the uhd maint branch in the last
>> couple days. Were any related to this issue?
>>
>> Andrew
>>
>> On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
>> wrote:
>>
>>> Hi Louis/Andrew,
>>>
>>> The root cause of the issue has been identified and a fix is in
>>> progress.  We should have the fix available on the head of the maint branch
>>> very soon.  Thank you for bringing it to our attention!
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 I have an issue that may be related. Using LFTX and LFRX boards in an
 X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
 with:

 terminate called after throwing an instance of 'std::out_of_range'
   what():  map::at

 Following for updates.

 Andrew


 On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello Louis:
>
> Thanks for the detailed feedback. We have reproduced this issue, and
> are debugging it now. We will get back to you and post an update shortly.
>
> --​Neel Pandeya
>
>
>
>
> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Could it be something to do with this commit for address offsets?
>>
>> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
>> 064b0dc6fbcc04c2ded94b4a
>>
>> Lou
>>
>>
>> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>>
>>
>> Did something change with respect to daughter board addressing in UHD
>> 3.11?
>> I have an X310 with LFTX and LFRX  in motherboard slot A.
>> When I run benchmark_rate it core dumps as follows:
>>
>> /*
>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>> "addr=192.168.40.2" --tx_rate=10E6
>>
>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
>> Boost_106400; UHD_3.11.0.1-0-unknown
>> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Determining maximum frame size...
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> [INFO] [X300] Setup basic communication...
>> [INFO] [X300] Loading values from EEPROM...
>> [INFO] [X300] Setup RF frontend clocking...
>> [INFO] [X300] Radio 1x clock:200
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
>> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1
>> input ports
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1
>> input ports
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> Using Device: Single USRP:
>> Device: X-Series Device
>> Mboard 0: X310
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: LFRX (AB)
>> RX Channel: 1
>> RX DSP: 0
>> RX Dboard: B
>> RX Subdev: Unknown (0x) - 0
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: LFTX (AB)
>> TX Channel: 1
>> TX DSP: 0
>> TX Dboard: B
>> TX Subdev: Unknown (0x) - 0
>>
>> [00:00:02.623786] Setting device timestamp to 0...
>> terminate called after throwing an instance of 'std::out_of_range'
>> what(): map::at
>> Aborted (core dumped)
>> */
>>
>>
>> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX
>> 

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Michael West via USRP-users]

Hi Andrew,

The fix is on the master branch (commit 8922095
).
It is being included in the next set of commits on the maint branch that
should be available in the next few days.

Regards,
Michael

On Wed, May 2, 2018 at 1:13 PM, switchlanez  wrote:

> Hi Michael,
>
> I see new commits have been entered in the uhd maint branch in the last
> couple days. Were any related to this issue?
>
> Andrew
>
> On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
> wrote:
>
>> Hi Louis/Andrew,
>>
>> The root cause of the issue has been identified and a fix is in
>> progress.  We should have the fix available on the head of the maint branch
>> very soon.  Thank you for bringing it to our attention!
>>
>> Regards,
>> Michael
>>
>> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I have an issue that may be related. Using LFTX and LFRX boards in an
>>> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
>>> with:
>>>
>>> terminate called after throwing an instance of 'std::out_of_range'
>>>   what():  map::at
>>>
>>> Following for updates.
>>>
>>> Andrew
>>>
>>>
>>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello Louis:

 Thanks for the detailed feedback. We have reproduced this issue, and
 are debugging it now. We will get back to you and post an update shortly.

 --​Neel Pandeya




 On 12 April 2018 at 18:46, Louis Brown via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Could it be something to do with this commit for address offsets?
>
> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
> 064b0dc6fbcc04c2ded94b4a
>
> Lou
>
>
> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>
>
> Did something change with respect to daughter board addressing in UHD
> 3.11?
> I have an X310 with LFTX and LFRX  in motherboard slot A.
> When I run benchmark_rate it core dumps as follows:
>
> /*
> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
> "addr=192.168.40.2" --tx_rate=10E6
>
> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
> Boost_106400; UHD_3.11.0.1-0-unknown
> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1
> input ports
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1
> input ports
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> Using Device: Single USRP:
> Device: X-Series Device
> Mboard 0: X310
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: LFRX (AB)
> RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: Unknown (0x) - 0
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: LFTX (AB)
> TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: Unknown (0x) - 0
>
> [00:00:02.623786] Setting device timestamp to 0...
> terminate called after throwing an instance of 'std::out_of_range'
> what(): map::at
> Aborted (core dumped)
> */
>
>
> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX
> LED, or course I have no boards installed there.
>
> /*
> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
> "addr=192.168.40.2" --tx_rate=100E6 --tx_channels "1"
> */
>
> If I specify tx_channels "0" it core dumps with the same
> std::out_of_range
>
> Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer run:
>
> /*
> [INFO] [CORES] Timer loopback test passed
> terminate called after throwing an instance of 'std::out_of_range'
> what(): map::at
> */
>

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[switchlanez via USRP-users]

Hi Michael,

I see new commits have been entered in the uhd maint branch in the last
couple days. Were any related to this issue?

Andrew

On Mon, Apr 23, 2018 at 11:12 AM, Michael West 
wrote:

> Hi Louis/Andrew,
>
> The root cause of the issue has been identified and a fix is in progress.
> We should have the fix available on the head of the maint branch very
> soon.  Thank you for bringing it to our attention!
>
> Regards,
> Michael
>
> On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I have an issue that may be related. Using LFTX and LFRX boards in an
>> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
>> with:
>>
>> terminate called after throwing an instance of 'std::out_of_range'
>>   what():  map::at
>>
>> Following for updates.
>>
>> Andrew
>>
>>
>> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello Louis:
>>>
>>> Thanks for the detailed feedback. We have reproduced this issue, and are
>>> debugging it now. We will get back to you and post an update shortly.
>>>
>>> --​Neel Pandeya
>>>
>>>
>>>
>>>
>>> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Could it be something to do with this commit for address offsets?

 https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
 064b0dc6fbcc04c2ded94b4a

 Lou


 On Apr 12, 2018, at 16:38, Louis Brown  wrote:


 Did something change with respect to daughter board addressing in UHD
 3.11?
 I have an X310 with LFTX and LFRX  in motherboard slot A.
 When I run benchmark_rate it core dumps as follows:

 /*
 [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
 "addr=192.168.40.2" --tx_rate=10E6

 [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
 Boost_106400; UHD_3.11.0.1-0-unknown
 [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
 [INFO] [X300] X300 initialization sequence...
 [INFO] [X300] Determining maximum frame size...
 [INFO] [X300] Maximum frame size: 8000 bytes.
 [INFO] [X300] Setup basic communication...
 [INFO] [X300] Loading values from EEPROM...
 [INFO] [X300] Setup RF frontend clocking...
 [INFO] [X300] Radio 1x clock:200
 [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
 [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
 [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
 [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
 [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1 input
 ports
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [RFNOC RADIO] Register loopback test passed
 [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1 input
 ports
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [RFNOC RADIO] Register loopback test passed
 [INFO] [CORES] Performing timer loopback test...
 [INFO] [CORES] Timer loopback test passed
 [INFO] [CORES] Performing timer loopback test...
 [INFO] [CORES] Timer loopback test passed
 Using Device: Single USRP:
 Device: X-Series Device
 Mboard 0: X310
 RX Channel: 0
 RX DSP: 0
 RX Dboard: A
 RX Subdev: LFRX (AB)
 RX Channel: 1
 RX DSP: 0
 RX Dboard: B
 RX Subdev: Unknown (0x) - 0
 TX Channel: 0
 TX DSP: 0
 TX Dboard: A
 TX Subdev: LFTX (AB)
 TX Channel: 1
 TX DSP: 0
 TX Dboard: B
 TX Subdev: Unknown (0x) - 0

 [00:00:02.623786] Setting device timestamp to 0...
 terminate called after throwing an instance of 'std::out_of_range'
 what(): map::at
 Aborted (core dumped)
 */


 If I specify tx_channels "1" it runs, lighting up the slot B TX/RX LED,
 or course I have no boards installed there.

 /*
 [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
 "addr=192.168.40.2" --tx_rate=100E6 --tx_channels "1"
 */

 If I specify tx_channels "0" it core dumps with the same
 std::out_of_range

 Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer run:

 /*
 [INFO] [CORES] Timer loopback test passed
 terminate called after throwing an instance of 'std::out_of_range'
 what(): map::at
 */

 If I try benchmark_rate with another X310 with the UBX card in slot A,
 things work fine.  So maybe it's specific to the use of LF cards with UHD
 3.11.

 Thanks,
 Lou




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


>>>
>>> ___
>>> USRP-users mailing list
>>> 

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[Michael West via USRP-users]

Hi Louis/Andrew,

The root cause of the issue has been identified and a fix is in progress.
We should have the fix available on the head of the maint branch very
soon.  Thank you for bringing it to our attention!

Regards,
Michael

On Fri, Apr 20, 2018 at 8:54 AM, switchlanez via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have an issue that may be related. Using LFTX and LFRX boards in an
> X310, anytime I use the RFNoC Radio block in Rx mode the run terminates
> with:
>
> terminate called after throwing an instance of 'std::out_of_range'
>   what():  map::at
>
> Following for updates.
>
> Andrew
>
>
> On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello Louis:
>>
>> Thanks for the detailed feedback. We have reproduced this issue, and are
>> debugging it now. We will get back to you and post an update shortly.
>>
>> --​Neel Pandeya
>>
>>
>>
>>
>> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Could it be something to do with this commit for address offsets?
>>>
>>> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
>>> 064b0dc6fbcc04c2ded94b4a
>>>
>>> Lou
>>>
>>>
>>> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>>>
>>>
>>> Did something change with respect to daughter board addressing in UHD
>>> 3.11?
>>> I have an X310 with LFTX and LFRX  in motherboard slot A.
>>> When I run benchmark_rate it core dumps as follows:
>>>
>>> /*
>>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>>> "addr=192.168.40.2" --tx_rate=10E6
>>>
>>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
>>> Boost_106400; UHD_3.11.0.1-0-unknown
>>> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
>>> [INFO] [X300] X300 initialization sequence...
>>> [INFO] [X300] Determining maximum frame size...
>>> [INFO] [X300] Maximum frame size: 8000 bytes.
>>> [INFO] [X300] Setup basic communication...
>>> [INFO] [X300] Loading values from EEPROM...
>>> [INFO] [X300] Setup RF frontend clocking...
>>> [INFO] [X300] Radio 1x clock:200
>>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
>>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
>>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
>>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
>>> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1 input
>>> ports
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1 input
>>> ports
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [RFNOC RADIO] Register loopback test passed
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> [INFO] [CORES] Performing timer loopback test...
>>> [INFO] [CORES] Timer loopback test passed
>>> Using Device: Single USRP:
>>> Device: X-Series Device
>>> Mboard 0: X310
>>> RX Channel: 0
>>> RX DSP: 0
>>> RX Dboard: A
>>> RX Subdev: LFRX (AB)
>>> RX Channel: 1
>>> RX DSP: 0
>>> RX Dboard: B
>>> RX Subdev: Unknown (0x) - 0
>>> TX Channel: 0
>>> TX DSP: 0
>>> TX Dboard: A
>>> TX Subdev: LFTX (AB)
>>> TX Channel: 1
>>> TX DSP: 0
>>> TX Dboard: B
>>> TX Subdev: Unknown (0x) - 0
>>>
>>> [00:00:02.623786] Setting device timestamp to 0...
>>> terminate called after throwing an instance of 'std::out_of_range'
>>> what(): map::at
>>> Aborted (core dumped)
>>> */
>>>
>>>
>>> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX LED,
>>> or course I have no boards installed there.
>>>
>>> /*
>>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>>> "addr=192.168.40.2" --tx_rate=100E6 --tx_channels "1"
>>> */
>>>
>>> If I specify tx_channels "0" it core dumps with the same
>>> std::out_of_range
>>>
>>> Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer run:
>>>
>>> /*
>>> [INFO] [CORES] Timer loopback test passed
>>> terminate called after throwing an instance of 'std::out_of_range'
>>> what(): map::at
>>> */
>>>
>>> If I try benchmark_rate with another X310 with the UBX card in slot A,
>>> things work fine.  So maybe it's specific to the use of LF cards with UHD
>>> 3.11.
>>>
>>> Thanks,
>>> Lou
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com

Re: [USRP-users] Core dump with UHD_3.11, X310, and LFTX

[switchlanez via USRP-users]

I have an issue that may be related. Using LFTX and LFRX boards in an X310,
anytime I use the RFNoC Radio block in Rx mode the run terminates with:

terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at

Following for updates.

Andrew

On Thu, Apr 19, 2018 at 9:54 AM, Neel Pandeya via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Louis:
>
> Thanks for the detailed feedback. We have reproduced this issue, and are
> debugging it now. We will get back to you and post an update shortly.
>
> --​Neel Pandeya
>
>
>
>
> On 12 April 2018 at 18:46, Louis Brown via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Could it be something to do with this commit for address offsets?
>>
>> https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2
>> 064b0dc6fbcc04c2ded94b4a
>>
>> Lou
>>
>>
>> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
>>
>>
>> Did something change with respect to daughter board addressing in UHD
>> 3.11?
>> I have an X310 with LFTX and LFRX  in motherboard slot A.
>> When I run benchmark_rate it core dumps as follows:
>>
>> /*
>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>> "addr=192.168.40.2" --tx_rate=10E6
>>
>> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5);
>> Boost_106400; UHD_3.11.0.1-0-unknown
>> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
>> [INFO] [X300] X300 initialization sequence...
>> [INFO] [X300] Determining maximum frame size...
>> [INFO] [X300] Maximum frame size: 8000 bytes.
>> [INFO] [X300] Setup basic communication...
>> [INFO] [X300] Loading values from EEPROM...
>> [INFO] [X300] Setup RF frontend clocking...
>> [INFO] [X300] Radio 1x clock:200
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0...
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
>> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1...
>> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
>> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1 input
>> ports
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1 input
>> ports
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [RFNOC RADIO] Register loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> [INFO] [CORES] Performing timer loopback test...
>> [INFO] [CORES] Timer loopback test passed
>> Using Device: Single USRP:
>> Device: X-Series Device
>> Mboard 0: X310
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: LFRX (AB)
>> RX Channel: 1
>> RX DSP: 0
>> RX Dboard: B
>> RX Subdev: Unknown (0x) - 0
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: LFTX (AB)
>> TX Channel: 1
>> TX DSP: 0
>> TX Dboard: B
>> TX Subdev: Unknown (0x) - 0
>>
>> [00:00:02.623786] Setting device timestamp to 0...
>> terminate called after throwing an instance of 'std::out_of_range'
>> what(): map::at
>> Aborted (core dumped)
>> */
>>
>>
>> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX LED,
>> or course I have no boards installed there.
>>
>> /*
>> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args
>> "addr=192.168.40.2" --tx_rate=100E6 --tx_channels "1"
>> */
>>
>> If I specify tx_channels "0" it core dumps with the same std::out_of_range
>>
>> Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer run:
>>
>> /*
>> [INFO] [CORES] Timer loopback test passed
>> terminate called after throwing an instance of 'std::out_of_range'
>> what(): map::at
>> */
>>
>> If I try benchmark_rate with another X310 with the UBX card in slot A,
>> things work fine.  So maybe it's specific to the use of LF cards with UHD
>> 3.11.
>>
>> Thanks,
>> Lou
>>
>>
>>
>>
>> ___
>> 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] Core dump with UHD_3.11, X310, and LFTX

[Louis Brown via USRP-users]

Could it be something to do with this commit for address offsets?

https://github.com/EttusResearch/uhd/commit/8ee22529f33a63c2064b0dc6fbcc04c2ded94b4a

Lou


> On Apr 12, 2018, at 16:38, Louis Brown  wrote:
> 
> 
> Did something change with respect to daughter board addressing in UHD 3.11?
> I have an X310 with LFTX and LFRX  in motherboard slot A.
> When I run benchmark_rate it core dumps as follows:
> 
> /*
> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args "addr=192.168.40.2" 
> --tx_rate=10E6
> 
> [INFO] [UHD] linux; GNU C++ version 7.3.1 20180303 (Red Hat 7.3.1-5); 
> Boost_106400; UHD_3.11.0.1-0-unknown
> [00:00:00.06] Creating the usrp device with: addr=192.168.40.2...
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size... 
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 0... 
> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1299 MB/s)
> [INFO] [RFNOC DMA FIFO] Running BIST for FIFO 1... 
> [INFO] [RFNOC DMA FIFO] BIST passed (Throughput: 1302 MB/s)
> [WARNING] [RFNOC] [0/Radio_0] defines 2 input buffer sizes, but 1 input ports
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [WARNING] [RFNOC] [0/Radio_1] defines 2 input buffer sizes, but 1 input ports
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test... 
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test... 
> [INFO] [CORES] Timer loopback test passed
> Using Device: Single USRP:
> Device: X-Series Device
> Mboard 0: X310
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: LFRX (AB)
> RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: Unknown (0x) - 0
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: LFTX (AB)
> TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: Unknown (0x) - 0
> 
> [00:00:02.623786] Setting device timestamp to 0...
> terminate called after throwing an instance of 'std::out_of_range'
> what(): map::at
> Aborted (core dumped)
> */
>  
> 
> If I specify tx_channels "1" it runs, lighting up the slot B TX/RX LED, or 
> course I have no boards installed there. 
> 
> /*
> [/usr/local/lib64/uhd/examples]$ ./benchmark_rate --args "addr=192.168.40.2" 
> --tx_rate=100E6 --tx_channels "1"
> */
> 
> If I specify tx_channels "0" it core dumps with the same std::out_of_range
> 
> Flow graphs that ran in UHD 3.10 with sub-device "A:AB" no longer run:
> 
> /*
> [INFO] [CORES] Timer loopback test passed
> terminate called after throwing an instance of 'std::out_of_range'
> what(): map::at
> */
> 
> If I try benchmark_rate with another X310 with the UBX card in slot A, things 
> work fine.  So maybe it's specific to the use of LF cards with UHD 3.11.
> 
> Thanks,
> Lou
>  
> 
> 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com