Re: [USRP-users] Problem with x310 io error

[Marcus D Leech via USRP-users]

What type of Ethernet connextion are you using?

What type of PC? Does your Ethernet card have an 82579LM controller chip?

Are you running under a VM or on the physical hardware?




Sent from my iPhone

> On Dec 12, 2020, at 11:19 PM, Basse Ang via USRP-users 
>  wrote:
> 
> Hi
> 
> Just have an issue, my x310 always get this error:
> 
> [INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100; UHD_3.15.0.0-release
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929b
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t 
> _endianness = uhd::ENDIANNESS_BIG]
>   at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:50
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
> (CE_00_Port_30) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
> uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long unsigned 
> int]
>   at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:151
> 
> Error: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response 
> packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
> uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long unsigned 
> int]
>   at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:151
> 
> 
> Anyone has experienced it too? Could you help me please. thank you.
> 
> Regards
> Bass
> ___
> 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] Problem with x310 io error

[Basse Ang via USRP-users]

Hi

Just have an issue, my x310 always get this error:

[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
UHD_3.15.0.0-release
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929b
[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG]
  at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:50
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
(CE_00_Port_30) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
[with uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long
unsigned int]
  at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:151

Error: EnvironmentError: IOError: Block ctrl (CE_00_Port_30) no response
packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
[with uhd::endianness_t _endianness = uhd::ENDIANNESS_BIG; uint64_t = long
unsigned int]
  at /build/uhd-wjAkGd/uhd-3.15.0.0-1/host/lib/rfnoc/ctrl_iface.cpp:151


Anyone has experienced it too? Could you help me please. thank you.

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

Re: [USRP-users] meta-ettus-v4.0.0.0 segfault

[Philip Balister via USRP-users]

On 12/11/20 4:49 PM, Philip Balister via USRP-users wrote:
> On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote:
>> Unfortunately, that FFTW bug has been around for a while. Issue 213 is a
>> duplicate of issue 182 from a year+ ago.
>>
>> https://github.com/FFTW/fftw3/issues/182
>>
>> On Ubuntu 20.04 armhf, they're just compiling the FFTW package without
>> NEON enabled.
> 
> I poked at this way more than I should have and am 99% certain the issue
> in in gcc-8. Building with -O off led to an fftw that would pass its
> make check. I tried a build on a qemuarm from OE/master and that worked
> (gcc-10). gcc-9 is a question, I fired up a build of OE/dunfell (gcc-9)
> and will run the qemu check and see what happens.

In the bad news, fftw qa tests fail in qemuarm with gcc9.

Philip

> 
> If you are stuck on zeus, you'll need to try and id the patch that fixes
> gcc and apply it to the gcc build. But getting off zeus would be a
> really bood move as it is out of support now.
> 
> Philip
> 
>>
>> Ron
>>
>> On 12/6/20 06:27, Ben Magistro via USRP-users wrote:
>>> Issue appears to be with the compiler that is included in Zeus (gcc
>>> 9.x vs 8.x) and an interaction with fftw. There is an open issue with
>>> fftw (https://github.com/FFTW/fftw3/issues/213) and a request to the
>>> yocto folks to request they consider adding back gcc-8.3 to zeus +
>>> dunfell (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14144)
>>> until this can be better resolved.  I think data point 3 confirms this
>>> as I did not include options to enable neon when I compiled.
>>>
>>> On Wed, Nov 11, 2020 at 1:39 PM Ben Magistro >> > wrote:
>>>
>>>     Adding some more data points.
>>>
>>>     1) I've been trying to rebuild meta-ettus-v4 with debug enabled
>>>     but am hitting an issue with image size and can't seem to get past
>>>     that.  It says I should increase `MENDER_STORAGE_TOTAL_SIZE_MB` if
>>>     the actual size is larger but increasing this seems to have no
>>>     effect.  I am using the ettus docker image for oe-builder with the
>>>     command `./meta-ettus/contrib/build_imgs_package.sh e310_sg3
>>>     v4.0.0.0`.  For the debug portion I've added a few lines to
>>>     `build/conf/local.conf` to add the packages. I'm open to
>>>     suggestions to build the image with debug symbols and provide
>>>     additional feedback.
>>>
>>>     2) I put together a simple flowgraph, UHD source --> frequency
>>>     xlating fft --> null sink.  This also segfaults, no guarantees
>>>     that I got the parameters correct.
>>>
>>>     3) Since the issues seem to be with fftw, I decided to try
>>>     building my own copy of fftw mostly to get debug symbols and
>>>     continue troubleshooting.  For this I used `./configure
>>>     --enable-debug --enable-shared --enable-threads --enable-float`
>>>     and `make CFLAGS="-ggdb"`.  These options are best guesses right
>>>     now since I didn't look at the layers to see what parameters it is
>>>     using (assuming it is in one of the layers).  Using this build
>>>     with `export LD_LIBRARY_PATH=/usr/local/lib/` I do not get a
>>>     segfault with gr-ais or the above flowgraph but I also don't get
>>>     the expected output which makes me question the parameters I used
>>>     to build it.  Output wise I get a string of "D" or "O" to the
>>> console.
>>>
>>>     Thanks
>>>
>>>     Ben
>>>
>>>     On Thu, Nov 5, 2020 at 9:22 AM Michael Dickens
>>>     mailto:michael.dick...@ettus.com>> wrote:
>>>
>>>     Hi Ben - This issue has been reported to R&D internally. If
>>>     you wish to create a public-facing UHD issue on our Github
>>>     tracker please go ahead & do so, and tag me on it so that we
>>>     can keep track of it internally. - MLD
>>>
>>>     On Wed, Nov 4, 2020 at 11:25 PM Ben Magistro via USRP-users
>>>     >>     > wrote:
>>>
>>>     Is anyone else using meta-ettus-v4.0.0.0 yet?  if so, have
>>>     you had any issues with libfftw?
>>>
>>>     Using the image on an E310, adding a single OOT module
>>>     (gr-ais) and trying to run an app distributed with it, the
>>>     app segfaults.  To further troubleshoot, I added gdb and
>>>     it comes back with the following.  I have a separate
>>>     development host that has gnuradio 3.8 setup using pybombs
>>>     and do not experience this issue there.
>>>
>>>     Thread 1 "python3" received signal SIGSEGV, Segmentation
>>>     fault.
>>>     0xb6947836 in ?? () from /usr/lib/libfftw3f.so.3
>>>
>>>     To compile, I've needed to override PYTHON_EXECUTABLE as
>>>     it points to a non-existent path in /home/oe-builder
>>>     in /usr/lib/cmake/gnuradio/GnuradioConfig.cmake. To run I
>>>     also needed to define LD_EXPORT_PATH pointing to
>>>     /usr/local/lib/.
>>>
>>>     Thanks in advance.

Re: [USRP-users] RFNoC 4.0 data swapping?

[Wade Fife via USRP-users]

Thanks for the updates. If you just want to reload the FPGA, try running
"overlay rm n310 && overlay add n310" on the N310. This should simply
reload the FPGA using the bistream already in the flash.

Wade

On Fri, Dec 11, 2020 at 6:45 PM Rob Kossler  wrote:

> Wade,
> The following also fails using just 2 blocks and 2 attempts:
>   host_tx => Switchboard#0 => Switchboard#1 => host_rx  // SUCCESS
>   host_tx => Switchboard#1 => Switchboard#0 => host_rx  // FAILURE (RX
> samples equal swapped I/Q of TX samples)
>
> In addition to wanting to get this issue fixed, I also have a question
> about the best way to "reboot" the N310 which is what I need to do to fix
> the issue after it occurs.  One way is to give the "reboot now" linux
> command.  But, this takes a long time.  Another way is to reprogram the
> FPGA image via uhd_image_loader. This is appreciably faster, but I'm
> thinking that this is not a great idea if the flash memory has a limited
> number of write cycles before failure.  Is there another way to achieve a
> reboot other than these two?
> Rob
>
> On Fri, Dec 11, 2020 at 7:34 PM Rob Kossler  wrote:
>
>> AHA!  I duplicated the issue with the Switchboard image.  The way to
>> duplicate the issue is the run the following series of graphs:
>>   host_tx => Switchboard#0 => Switchboard#1 => host_rx  // SUCCESS
>>   host_tx => Switchboard#2 => Switchboard#3 => host_rx  // SUCCESS
>>   host_tx => Switchboard#0 => Switchboard#2 => host_rx  // FAILURE (RX
>> samples equal swapped I/Q of TX samples)
>> Each of these 3 runs consists of running my application (similar to one
>> of the examples such as rfnoc_rx_to_file) such that the UHD object is
>> re-created each time.  My guess is that you could use gnuradio to do it
>> instead.
>>
>> My working theory is that the problem is caused by the fact that the
>> Switchboard#2 input port was changed from being connected to the host in
>> test case 2 to then be connected to another RFNoC block in test case 3.
>> Or, I suppose it could be the output port on this block (same logic).
>>
>> If you want me to send you my FPGA image with the 4 Switchboard blocks,
>> let me know.
>> Rob
>>
>>
>>
>> On Fri, Dec 11, 2020 at 7:09 PM Rob Kossler  wrote:
>>
>>> Hi Wade,
>>> After thinking about it a bit, I would ignore the "negation" issue for
>>> now. This may be a byproduct of I/Q swapping related to my custom block.
>>> Rob
>>>
>>> On Fri, Dec 11, 2020 at 6:34 PM Rob Kossler  wrote:
>>>
 Hi Wade,
 Thanks for the info.  I still do not know what's going on, but here are
 a few updates:

- I built a new N310 image with 4 switchboards (1x1) and 1
splitstream (1x2) blocks in addition to the default blocks.  All of the
additional blocks are connected to SEPs for dynamic linking.  I tried my
best to get bad behavior using a chain of 1 to 4 switchboards, but I 
 could
not duplicate any I/Q swapping or negation issues.
- I went back to my custom image (that I described below) and found
different behavior today (sometimes things worked OK).  So, this got me 
 to
thinking that I am somehow getting the FPGA in a bad state such that a
reboot (or FPGA re-flashing) fixes things.  I have had some success with
re-booting and things working properly.  But, I still do not have a true
handle on things and cannot adequately predict when things are going to
succeed or fail.
- One thing that has been constant is that I have never seen bad
behavior when I only have 1 block in my graph (no matter which block I
choose).  Note that for all of my tests, the graph looks like this: 
 host_tx
=> block_chain => host_rx, where block_chain is a sequential chain of 1 
 or
more rfnoc blocks.

 I will send a follow up once I figure things out.
 Rob


 On Fri, Dec 11, 2020 at 6:22 PM Wade Fife  wrote:

> Hi Rob,
>
> The SEPs do have the ability to swap I and Q. This is because on the
> host computer, I is usually in the lower bits and Q is in the upper bits 
> of
> each 32-bit word, but in RFNoC, for historical reasons, I goes in the 
> upper
> bits and Q in the lower bits. The software programs the IQ swapping when 
> it
> sets up the graph.
>
> I assume you're using dynamic connections (through the crossbar) to
> control the number of FFTs the data is passed through, and not static
> connections? If that's the case then I wonder if software configures IQ
> swapping incorrectly in some configurations. I'll see if I can do some
> testing next week to confirm if it's working correctly.
>
> As for negation, I'm not aware of anywhere we do that off the top of
> my head. Is that behavior block dependent? I'll see if I can find anywhere
> this happens.
>
> Thanks,
>
> Wade
>
> On Thu, Dec 10, 2020 at 3:54 PM Rob Kossler