Hi Gabriel, aha! That's in GNU Radio's multiply block, using libVOLK, so this is something that we might actually hunt down. I remember there being awareness of a similar error not too long ago, put Philip Balister in CC:; he had a problem with the neonasm implementation of dot product, so he used neon instead.
to help me debug this: the output of "volk-config-info -v --all-machines" would be helpful, and also whether "volk_config -b" runs (that will definitely take a while!) without segfault. Best regards, Marcus On 01.02.2016 20:25, Gabriel Pechiarovich wrote: > After receiving SIGSEGV, i've used backtrace and got this: > > Press Enter to quit: > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x9a4ff460 (LWP 3392)] > .tailcase () > at > /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36 > 36 vld1.32 d0, [r2]! @ s0, s1 = br, bi > (gdb) backtrace > #0 .tailcase () > at > /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36 > #1 0xb6992774 in gr::blocks::multiply_cc_impl::work (this=<optimized > out>, > noutput_items=4096, input_items=..., output_items=...) > at > /usr/src/debug/gnuradio/3.7.7-r0/git/gr-blocks/lib/multiply_cc_impl.cc:60 > #2 0x9a4fede4 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) > > > 2016-02-01 14:18 GMT-05:00 Marcus Müller <marcus.muel...@ettus.com > <mailto:marcus.muel...@ettus.com>>: > > ah sorry, that was confusing: > after SIGILL, please "continue", untill you get SIGSEGV, then type > "backtrace". > > Best regards, > Marcus > > > On 01.02.2016 20:08, Gabriel Pechiarovich wrote: >> Hi, this is the full output: >> >> >> set_min_output_buffer on block 10 to 96000 >> set_min_output_buffer on block 12 to 96000 >> set_min_output_buffer on block 14 to 96000 >> set_min_output_buffer on block 15 to 96000 >> set_min_output_buffer on block 18 to 96000 >> set_min_output_buffer on block 29 to 96000 >> [New Thread 0xa48e5460 (LWP 3255)] >> [New Thread 0xa40e5460 (LWP 3256)] >> [New Thread 0xa36ff460 (LWP 3258)] >> [New Thread 0xa2eff460 (LWP 3257)] >> [New Thread 0xa24ff460 (LWP 3259)] >> [New Thread 0xa1cff460 (LWP 3260)] >> [New Thread 0xa14ff460 (LWP 3261)] >> [New Thread 0xa0cff460 (LWP 3262)] >> [New Thread 0xa04ff460 (LWP 3263)] >> [New Thread 0x9fcff460 (LWP 3264)] >> [New Thread 0x9f4ff460 (LWP 3265)] >> [New Thread 0x9ecff460 (LWP 3266)] >> [New Thread 0x9e4ff460 (LWP 3267)] >> [New Thread 0x9dcff460 (LWP 3268)] >> [New Thread 0x9d4ff460 (LWP 3269)] >> [New Thread 0x9ccff460 (LWP 3270)] >> [New Thread 0x9c4ff460 (LWP 3271)] >> [New Thread 0x9bcff460 (LWP 3272)] >> [New Thread 0x9b4ff460 (LWP 3273)] >> [New Thread 0x9acff460 (LWP 3274)] >> [New Thread 0x9a4ff460 (LWP 3275)] >> [New Thread 0x99cff460 (LWP 3276)] >> [New Thread 0x994ff460 (LWP 3277)] >> [New Thread 0x98cff460 (LWP 3278)] >> [New Thread 0x984ff460 (LWP 3279)] >> [New Thread 0x97cff460 (LWP 3280)] >> [New Thread 0x974ff460 (LWP 3281)] >> [New Thread 0x96cff460 (LWP 3282)] >> [New Thread 0x964ff460 (LWP 3283)] >> [New Thread 0x95cff460 (LWP 3284)] >> [New Thread 0x954ff460 (LWP 3285)] >> [New Thread 0x94cff460 (LWP 3286)] >> [New Thread 0x944ff460 (LWP 3287)] >> [New Thread 0x93cff460 (LWP 3288)] >> [New Thread 0x934ff460 (LWP 3289)] >> [New Thread 0x92cff460 (LWP 3290)] >> [New Thread 0x924ff460 (LWP 3291)] >> [New Thread 0x91cff460 (LWP 3292)] >> [New Thread 0x914ff460 (LWP 3293)] >> [New Thread 0x90cff460 (LWP 3294)] >> >> Press Enter to quit: >> Program received signal *SIGSEGV*, Segmentation fault. >> [Switching to Thread 0x9a4ff460 (LWP 3275)] >> .tailcase () >> at >> >> /usr/src/debug/volk/1.0.0-r0/git/kernels/volk/asm/neon/volk_32fc_x2_multiply_32fc_neonasm.s:36 >> 36 vld1.32 d0, [r2]! @ s0, s1 = br, bi >> >> (gdb) continue >> Continuing. >> [Thread 0x90cff460 (LWP 3294) exited] >> [Thread 0x914ff460 (LWP 3293) exited] >> [Thread 0x91cff460 (LWP 3292) exited] >> [Thread 0x924ff460 (LWP 3291) exited] >> [Thread 0x92cff460 (LWP 3290) exited] >> [Thread 0x934ff460 (LWP 3289) exited] >> [Thread 0x93cff460 (LWP 3288) exited] >> >> [Thread 0x93cff460 (LWP 3288) exited] >> [Thread 0x944ff460 (LWP 3287) exited] >> [Thread 0x94cff460 (LWP 3286) exited] >> [Thread 0x954ff460 (LWP 3285) exited] >> [Thread 0x95cff460 (LWP 3284) exited] >> [Thread 0x964ff460 (LWP 3283) exited] >> [Thread 0x96cff460 (LWP 3282) exited] >> [Thread 0x974ff460 (LWP 3281) exited] >> [Thread 0x97cff460 (LWP 3280) exited] >> [Thread 0x984ff460 (LWP 3279) exited] >> [Thread 0x98cff460 (LWP 3278) exited] >> [Thread 0x994ff460 (LWP 3277) exited] >> [Thread 0x99cff460 (LWP 3276) exited] >> [Thread 0x9a4ff460 (LWP 3275) exited] >> [Thread 0x9acff460 (LWP 3274) exited] >> [Thread 0x9b4ff460 (LWP 3273) exited] >> [Thread 0x9bcff460 (LWP 3272) exited] >> [Thread 0x9c4ff460 (LWP 3271) exited] >> [Thread 0x9ccff460 (LWP 3270) exited] >> [Thread 0x9dcff460 (LWP 3268) exited] >> [Thread 0x9e4ff460 (LWP 3267) exited] >> [Thread 0x9ecff460 (LWP 3266) exited] >> [Thread 0x9f4ff460 (LWP 3265) exited] >> [Thread 0x9fcff460 (LWP 3264) exited] >> [Thread 0xa04ff460 (LWP 3263) exited] >> [Thread 0xa0cff460 (LWP 3262) exited] >> [Thread 0xa14ff460 (LWP 3261) exited] >> [Thread 0xa1cff460 (LWP 3260) exited] >> [Thread 0xa24ff460 (LWP 3259) exited] >> [Thread 0xa36ff460 (LWP 3258) exited] >> [Thread 0xa2eff460 (LWP 3257) exited] >> [Thread 0xa40e5460 (LWP 3256) exited] >> [Thread 0xa48e5460 (LWP 3255) exited] >> [Thread 0xb6ffa000 (LWP 3244) exited] >> >> Program terminated with signal SIGSEGV, Segmentation fault. >> The program no longer exists. >> (gdb) >> >> >> 2016-02-01 13:59 GMT-05:00 Marcus Müller >> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>: >> >> Lack of a library wouldn't cause this; what's the "backtrace" >> output after gdb tells you the program segfaulted? >> >> Best regards, >> Marcus >> >> >> On 01.02.2016 19:57, Gabriel Pechiarovich wrote: >>> Hi, >>> as you foretold it actually crashed with SIGSEGV >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> >>> This may be a problem with the onboard linux on the E310, >>> maybe lacks something. >>> Gabriel Pechiarovich >>> >>> 2016-02-01 13:11 GMT-05:00 Marcus Müller >>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>: >>> >>> Hi Gabriel, >>> >>> that might actually be part of OpenSSL's CPU feature >>> detection, be caught and handled normally; maybe it's >>> hiding another fault. I assume when you type "continue" >>> on the gdb prompt the program actually crashes with SIGSEGV? >>> >>> Best regards, >>> Marcus >>> >>> >>> On 01.02.2016 18:54, Gabriel Pechiarovich wrote: >>>> Hi >>>> I used the backtrace and got this: >>>> >>>> (gdb) run wifi_loopback_ngui.py >>>> Starting program: /usr/bin/python wifi_loopback_ngui.py >>>> [Thread debugging using libthread_db enabled] >>>> Using host libthread_db library "/lib/libthread_db.so.1". >>>> >>>> Program received signal SIGILL, Illegal instruction. >>>> _armv7_tick () at armv4cpuid.S:17 >>>> 17 mrc p15,0,r0,c9,c13,0 >>>> (gdb) bt >>>> #0 _armv7_tick () at armv4cpuid.S:17 >>>> #1 0xb48238a8 in OPENSSL_cpuid_setup () at armcap.c:75 >>>> #2 0xb6fe70d4 in call_init (l=<optimized out>, >>>> argc=argc@entry=2, >>>> argv=argv@entry=0xbefffd64, >>>> env=env@entry=0xbefffd70) at dl-init.c:78 >>>> #3 0xb6fe7230 in call_init (env=<optimized out>, >>>> argv=<optimized out>, >>>> argc=<optimized out>, l=<optimized out>) at >>>> dl-init.c:36 >>>> #4 _dl_init (main_map=main_map@entry=0x1074500, >>>> argc=2, argv=0xbefffd64, >>>> env=0xbefffd70) at dl-init.c:126 >>>> #5 0xb6febb2c in dl_open_worker (a=<optimized out>) at >>>> dl-open.c:566 >>>> #6 0xb6fe6f80 in _dl_catch_error (objname=0xb6ffa510, >>>> objname@entry=0xbefdd32c, errstring=0xbefdd3c0, >>>> errstring@entry=0xbefdd330, mallocedp=0xbefdd32c, >>>> mallocedp@entry=0xbefdd32b, operate=0xbefdd330, >>>> args=args@entry=0xbefdd334) >>>> at dl-error.c:187 >>>> #7 0xb6feb1d0 in _dl_open ( >>>> file=0xbefdd86c >>>> "/usr/lib/python2.7/lib-dynload/_hashlib.so", >>>> mode=-2147483646, caller_dlopen=0xb6f444a4 >>>> <_PyImport_GetDynLoadFunc+324>, >>>> nsid=-2, argc=2, argv=0xbefffd64, env=0xbefffd70) >>>> at dl-open.c:650 >>>> #8 0xb6cebb9c in dlopen_doit (a=0xbefdd580) at dlopen.c:66 >>>> #9 0xb6fe6f80 in _dl_catch_error (objname=0xb6ffa510, >>>> errstring=0x0, >>>> mallocedp=0xa91f4, operate=0xa91f8, >>>> args=0xbefdd580) at dl-error.c:187 >>>> #10 0xb6cec2ac in _dlerror_run (operate=0xb6cebb20 >>>> <dlopen_doit>, >>>> args=args@entry=0xbefdd580) at dlerror.c:163 >>>> ---Type <return> to continue, or q <return> to quit--- >>>> >>>> >>>> I'm not a programer but i can understand some things. >>>> The modifications i've made to the loopback are >>>> basicaly changing all the gui >>>> >>>> 2016-02-01 11:49 GMT-05:00 Bastian Bloessl >>>> <bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org>>: >>>> >>>> Hi, >>>> >>>> if you don’t have another USRP that works with a PC >>>> (like B210 or N210) and really have to get it >>>> running on the E310 you should do a backtrace. >>>> >>>> It's hard to tell what’s going wrong from just the >>>> fact that something segfaults. >>>> >>>> Best, >>>> Bastian >>>> >>>> -- >>>> Dipl.-Inform. Bastian Bloessl >>>> Distributed Embedded Systems Group >>>> University of Paderborn, Germany >>>> http://www.ccs-labs.org/~bloessl/ >>>> <http://www.ccs-labs.org/%7Ebloessl/> >>>> >>>>> On 01 Feb 2016, at 08:37, Gabriel Pechiarovich >>>>> <gaps.18.2...@gmail.com >>>>> <mailto:gaps.18.2...@gmail.com>> wrote: >>>>> >>>>> Hi, >>>>> I installed the module by coping the files needed >>>>> to the E310 then I compiled them on the E310, the >>>>> needed libraries like itpp were downloaded and >>>>> copied as well. >>>>> I've installed in this order (install using cmake >>>>> make ...): ITPP 4.3.1 gr-foo-master >>>>> gr-ieee802-11-master >>>>> I wanted to run the ieee802 in this device since i >>>>> cant run it on the USRP1 and i want to see the >>>>> spectrum with an analyzer, so i can compare with a >>>>> standard wifi transmitter. >>>>> I'm running the third image of the E310. >>>>> >>>>> 2016-01-29 14:01 GMT-05:00 Bastian Bloessl >>>>> <bloe...@ccs-labs.org <mailto:bloe...@ccs-labs.org>>: >>>>> >>>>> Hi, >>>>> >>>>> >>>>>> On 29 Jan 2016, at 10:16, Gabriel >>>>>> Pechiarovich <gaps.18.2...@gmail.com >>>>>> <mailto:gaps.18.2...@gmail.com>> wrote: >>>>>> >>>>>> Hi all, I just installed this module in my >>>>>> E310, to run the loopback in the E310 i >>>>>> modified the flow graph so it is no gui, but >>>>>> when i'm running in the E310 i got a >>>>>> segmentation fault and the program stops: >>>>> >>>>> How did you install the module? Did you >>>>> compile it on the E310? >>>>> >>>>>> >>>>>> root@ettus-e300:~/wifi-master# python >>>>>> wifi_loopback_ngui.py >>>>>> linux; GNU C++ version 4.9.1; Boost_105600; >>>>>> UHD_003.008.005-0-unknown >>>>>> >>>>>> Using Volk machine: neon_hardfp >>>>>> OFDM MAPPER: encoding: 0 >>>>>> set_min_output_buffer on block 10 to 96000 >>>>>> set_min_output_buffer on block 12 to 96000 >>>>>> set_min_output_buffer on block 14 to 96000 >>>>>> set_min_output_buffer on block 15 to 96000 >>>>>> Segmentation fault >>>>>> root@ettus-e300:~/wifi-master# >>>>> >>>>> >>>>> I think you should try to get a backtrace. I >>>>> use something like >>>>> >>>>> gdb python >>>>> run wifi_loopback.py >>>>> <wait for crash> >>>>> bt >>>>> >>>>> >>>>>> >>>>>> I need to run at least the loopback >>>>>> thank you in andvance >>>>>> >>>>> >>>>> If you are interested in simulations only, >>>>> there is really no need to run them on the E310. >>>>> >>>>> Best, >>>>> Bastian >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gabriel Pechiarovich Salas >>>>> Red Dragon Games >>>>> Designers and game developers >>>> >>>> >>>> >>>> >>>> -- >>>> Gabriel Pechiarovich Salas >>>> Red Dragon Games >>>> Designers and game developers >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> >>> >>> -- >>> Gabriel Pechiarovich Salas >>> Red Dragon Games >>> Designers and game developers >> >> >> >> >> -- >> Gabriel Pechiarovich Salas >> Red Dragon Games >> Designers and game developers > > > > > -- > Gabriel Pechiarovich Salas > Red Dragon Games > Designers and game developers
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
