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.
I wonder if the fix is similar to the problem mentioned for AVX in the 3.3.8 release notes: http://www.fftw.org/release-notes.html Philip > > https://github.com/FFTW/fftw3/issues/182 > > On Ubuntu 20.04 armhf, they're just compiling the FFTW package without > NEON enabled. > > 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 <konce...@gmail.com >> <mailto: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 <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 >> <usrp-users@lists.ettus.com >> <mailto: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 >> <mailto: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 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
