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 <konce...@gmail.com> 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 <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 < >> usrp-users@lists.ettus.com> 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. >>> _______________________________________________ >>> 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
