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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
