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 <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 > _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
