Don't use SG3, unless you know you've got a speedgrade 3 device -- use sg1.
Best regards, Marcus On 01.02.2016 21:21, Gabriel Pechiarovich wrote: > Hi all > > I'm using the third image of the E310 (sdimage-gnuradio-dev.direct.xz > <http://files.ettus.com/e3xx_images/e3xx-release-3/sdimage-gnuradio-dev.direct.xz>) > http://files.ettus.com/e3xx_images/e3xx-release-3/ > > I will donwload the fourth image, i think is the sg3: > > http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/ > > I will notice the results. > > Thank you all :) > > > 2016-02-01 15:01 GMT-05:00 Marcus Müller <marcus.muel...@ettus.com > <mailto:marcus.muel...@ettus.com>>: > > 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 >> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> 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 >>> <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 <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 >>>>>> <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 <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > > > -- > 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
