Hi Nathan, exactly the right lead. I had "GNU Radio something.8" in mind when I asked myself what version Gabriel was using. Scrolling down I figured Gabriel uses /UHD 3.8.something/, which I must have confused with the GNU Radio version. Gabriel, is it an option to use a more modern SD card image release? Yours, as Nathan explained, has bugs, and is quite dated.
Best regards, Marcus On 01.02.2016 20:56, West, Nathan wrote: > On Mon, Feb 1, 2016 at 2:39 PM, Marcus Müller > <[email protected] <mailto:[email protected]>> wrote: > > 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. > > > https://github.com/gnuradio/volk/issues/25#event-351452447 > relevant commit for > multiply: > https://github.com/gnuradio/volk/commit/92a7251bc9b26ab7bd03cd4fbbd6ee2f0c6f3cef > > > > 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. > > > You may just be on an 'old' version of volk. If so either upgrade or > set volk_config appropriately. > > > > 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 >> <[email protected] <mailto:[email protected]>>: >> >> 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 >>> <[email protected] <mailto:[email protected]>>: >>> >>> 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 >>>> <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> 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 <tel: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 >>>>> <[email protected] <mailto:[email protected]>>: >>>>> >>>>> 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 <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>>>> <[email protected] >>>>>> <mailto:[email protected]>>: >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>>> On 29 Jan 2016, at 10:16, Gabriel >>>>>>> Pechiarovich <[email protected] >>>>>>> <mailto:[email protected]>> 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 >>>>> [email protected] >>>>> <mailto:[email protected]> >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] >>>> <mailto:[email protected]> >>>> 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 > [email protected] <mailto:[email protected]> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
