Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

Added issue https://github.com/gnuradio/gnuradio/issues/1554 On Sun, Jan 21, 2018 at 7:38 AM, Jeff Long wrote: > Ah, good. I didn't think it needed another +1 but couldn't think of any > other overflow. > > On Sun, Jan 21, 2018 at 7:33 AM, Jeff Long wrote: > >> The forecast function is supposed

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

Ah, good. I didn't think it needed another +1 but couldn't think of any other overflow. On Sun, Jan 21, 2018 at 7:33 AM, Jeff Long wrote: > The forecast function is supposed to guarantee that there is enough input, > but it might be rounding down in some cases. Could you try adding the "+1" to

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

The forecast function is supposed to guarantee that there is enough input, but it might be rounding down in some cases. Could you try adding the "+1" to the last line and see if that changes anything? void pfb_clock_sync_ccf_impl::forecast(int noutput_items, gr_v

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

El 21/01/18 a las 12:35, Daniel Estévez escribió: > El 21/01/18 a las 11:39, Daniel Estévez escribió: >> >> out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]); >> > > Hi all, > > I've been looking at this again and the problem is that in this line, > > count = -134217704 > >

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

El 21/01/18 a las 11:39, Daniel Estévez escribió: > > out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]); > Hi all, I've been looking at this again and the problem is that in this line, count = -134217704 for some weird reason. Obviously, this causes the SIGSEGV. I'll try

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

El 21/01/18 a las 12:01, Sakthivel Velumani escribió: > Hi Daniel, > > The pfb block sets history() to ensure sufficient amount of input items > are available. Can you provide information on arguments passed to the > pfb block like sps, taps and no. of filters? Hi Sakthivel, The parameters I'm u

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

Hi Daniel, The pfb block sets history() to ensure sufficient amount of input items are available. Can you provide information on arguments passed to the pfb block like sps, taps and no. of filters? Best, Sakthivel On Sun, Jan 21, 2018 at 11:39 AM, Daniel Estévez wrote: > Hi all, > > I'm using

[Discuss-gnuradio] Segfault in Polyphase clock sync block

Hi all, I'm using a Polyphase clock sync block in one of my flowgraphs (https://github.com/daniestevez/gr-satellites/blob/master/apps/picsat.grc) and I'm getting a segmentation fault when running the flowgraph. Using GDB, the problem seems to be in the Polyphase clock implementation, when filteri

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

On Wed, 2016-12-07 at 12:10 -0500, Andy Walls wrote: > > From GDB I can see > > > > > > d_filtnum = 0 > > count = -67108696 > > d_out_idx = 0 > > > > This is a garbage-in, garbage-out problem I've seen exactly before with > other blocks and the PFB clock sync block. > > 1. Check to make sure

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Typo in there count can never be less than 0. The other thing that I think makes sense is that we might need some history to scroll back to, but I don't think it's necessarily bounded how much history... Are you using an upstream block that provides time_est tags? Also, what parameters are you

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

> From: > devin kelly > Subject: > Re: [Discuss-gnuradio] Segfault > with > volk_32fc_32f_dot_prod_32fc_a_avx > Date: > Wed, 7

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Some sanity appears! >From what I can tell, count is keeping track of how many input samples have been processed, which can never be 0. My proposed fix would be to clamp count to 0 somewhere after line 462, but it would be nice for someone to confirm this makes sense. Nathan On Wed, Dec 7, 2016

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

I rebuilt GR with CMAKE_BUILD_TYPE=Debug. The al and ar vairables got optimized out, what's the compiler option to prevent that? I think I've found part of the problem: Looking here (on frame 2 in gdb): https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Hi, hm, you're right, the only way that can happen is if either the input or the tap pointers are invalid; strange. Since the line in question, 465 out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]); in pfb_clock_sync_ccf.cc isn't all that suspicious, let's harass GD

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

On Tue, Dec 6, 2016 at 1:24 PM, devin kelly wrote: > I changed my volk_config like so > > volk_32fc_32f_dot_prod_32fc generic generic > > And I still get a segfault: > > gdb python core.8035 > > . > > Program terminated with signal 11, Segmentation fault. > #0 0x7f116379277f in volk_32f

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

I changed my volk_config like so volk_32fc_32f_dot_prod_32fc generic generic And I still get a segfault: gdb python core.8035 . Program terminated with signal 11, Segmentation fault. #0 0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic (result=0x56de260, input=0x7f1126cac680, tap

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

It's a bit of both. The segfault usually happens on packet between packets 2 and 3 (I send one packet per second on my transmitter) but sometimes will happen a few packets later. It also always segfaults, I've gotten it to segfault about 20 times or so. On Tue, Dec 6, 2016 at 12:24 PM, West, Nat

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but that's a separate topic. You can configure VOLK to not use this protokernel and there's some documentation on how to do it here: http://gnuradio.org/doc/doxygen/volk_guide.html#volk_tuning This is fairly concerning though...

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

OK, I tried a brand new GR/Volk install and still had the same problem. So no problem with re-linking Volk to GR. Could this be an issue with Volk on GCC 4.8.5? The newest GCC is 6.2 so 4.8.5 is pretty old, though the newest for Red Hat 7. Is there any way to reconfigure volk to not use volk_32

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Oh, that's pretty interesting! Well, no misconfiguration should segfault, so I'm a bit stumped at the moment. On 12/01/2016 06:14 PM, devin kelly wrote: > Marcus, > > Thanks for taking the time. It is possible I re-installed a new > version of VOLK. I'll try a fresh build and see what that gets

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Marcus, Thanks for taking the time. It is possible I re-installed a new version of VOLK. I'll try a fresh build and see what that gets me. I also should have mentioned that the filter works OK for a while then segfaults. A couple of packets always pass through the clock sync block I'm using be

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Hi Devin, I don't think it's a kernel problem – all your calculations happen in userland, and the kernel has not much to say with respect to the instructions used. The most common reason for this kind of misbehaviour is in fact a problem with how the application (in this case, your GNU Radio appl

[Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Hello, I'm having a problem with the above VOLK function segfaulting. I don't think I'm passing any incorrect values to VOLK. My problem could be that I'm on RHEL7 with (obviously) an older kernel: $ uname -a Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55 EST 2016 x86_

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

Good news! That branch now belongs in GNU Radio. Cheers, Nathan On Wed, Mar 9, 2016 at 8:45 AM, devin kelly wrote: > Thanks for the help, I don't think I could have figured this out on my own. > > This is because I'm on RHEL7 (argh!). My libfftw.so doesn't contain any > references to AVX. For

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

To answer your question however, he's misguided. Fftw and volk both have methods (volk_profile, fftw-wisdom) to profile and determine the best instructions to use for cases where they have multiple options, it's not going to get noticeably slower by compiling the extra stuff in. On Mar 9, 2016 8:47

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

I would use fftw source from their site not rhels source rpm, unless you need to deploy it on a large number of machines. (Even then I would pull latest source and update the srpm) You can just build fftw from source. Add almost all the configure options. We do this on rhel 6 because their version

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

Thanks for the help, I don't think I could have figured this out on my own. This is because I'm on RHEL7 (argh!). My libfftw.so doesn't contain any references to AVX. For me there are a couple of options for fixing this: 1) Use Nathan's branch. 2) Rebuild fftw with AVX support 3) Rebuild GR and

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

The a and c vectors come from gr:fft objects' internal buffers. These are internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc). fftwf_malloc is obviously not generating buffers with proper alignment so you're seeing a 50% (per buffer) that this segfaults. I'll note that this is

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

OK, here's my C program: #include #include #include #include int main() { size_t alignment = volk_get_alignment(); uint8_t* ptr; ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment); printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr, *ptr); volk_

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

On Tue, Mar 8, 2016 at 10:58 AM, devin kelly wrote: > Calling 'info variables' (or args or locals) the last few frames didn't > give me any real info so I built a copy of GR/Volk with debug symbols. I > ran the FG again, this time from GDB, here's my back trace. In this > backtrace you can see

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

Here's a simpler FG that I can use to reproduce this error. Hopefully it actually works for someone else. Devin On Tue, Mar 8, 2016 at 10:58 AM, devin kelly wrote: > Calling 'info variables' (or args or locals) the last few frames didn't > give me any real info so I built a copy of GR/Volk wit

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

Calling 'info variables' (or args or locals) the last few frames didn't give me any real info so I built a copy of GR/Volk with debug symbols. I ran the FG again, this time from GDB, here's my back trace. In this backtrace you can see the arguments passed in each call. I have an i7-5600U CPU @ 2

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

On Mon, Mar 7, 2016 at 10:18 PM, West, Nathan wrote: > On Mon, Mar 7, 2016 at 2:32 PM, devin kelly wrote: > >> Hello, >> >> I've built a flowgraph (grc, python attached) that usually (but not >> always) produces a segfaults in volk_32fc_x2_multiply_32fc_a_avx2_fma. The >> segfault occurs in the

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

On Mon, Mar 7, 2016 at 2:32 PM, devin kelly wrote: > Hello, > > I've built a flowgraph (grc, python attached) that usually (but not > always) produces a segfaults in volk_32fc_x2_multiply_32fc_a_avx2_fma. The > segfault occurs in the FFT filter in correlation estimator block. I'm not > sure if

[Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

Hello, I've built a flowgraph (grc, python attached) that usually (but not always) produces a segfaults in volk_32fc_x2_multiply_32fc_a_avx2_fma. The segfault occurs in the FFT filter in correlation estimator block. I'm not sure if it's the Volk code that's causing the segfault or the GR code ca

Re: [Discuss-gnuradio] SEGFAULT when using GR_LOG_INFO

Does someone could help me to fix it? I really need to use this feature, and I don't know what I am doing wrong... Thanks -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mail

[Discuss-gnuradio] SEGFAULT when using GR_LOG_INFO

Hi everyone, I want to use logging in GNURadio. I followed this link to use the logger : https://gnuradio.org/doc/doxygen/page_logger.html. I modified my CMakiefile.txt to link LOG4CPP dirs & libs. I added the FindLog4cpp.module file in cmake/Modules folder. I used the -DENABLE_GR_LOG=on paramete

Re: [Discuss-gnuradio] segfault

THANKS!! Yes...i did have 2 installations...removed the ones from package manager did the trick! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] segfault

>Is this what you meant? Exactly! So let's have a look at the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x76001d2f in pmt::string_to_symbol(std::string const&) () from / usr/local/lib/libgnuradio-pmt-3.7.6git.so.0.0.0 (gdb) bt #0 0x76001d2f in pmt::string_to

Re: [Discuss-gnuradio] segfault

Hi Michele - It looks like there are multiple GNU Radio installs being caught in the execution: /usr/local/lib/ and /usr/lib/x86_64-linux-gnu/ : {{{ Program received signal SIGSEGV, Segmentation fault. 0x76001d2f in pmt::string_to_symbol(std::string const&) () from / usr/local/lib/libgnura

Re: [Discuss-gnuradio] segfault

Il Sun, 30 Nov 2014 21:16:12 +0100, Marcus Müller ha scritto: > Hi Michele, > > if you built GNU Radio/gqrx with gcc, then the GNU Debugger might be of > immensive help. > First make sure you've built GNU Radio with debugging symbols ("cmake > -DCMAKE_BUILD_TYPE=RelWithDebInfo [...]"), then star

Re: [Discuss-gnuradio] segfault

Hi Michele, if you built GNU Radio/gqrx with gcc, then the GNU Debugger might be of immensive help. First make sure you've built GNU Radio with debugging symbols ("cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo [...]"), then start gqrx in the debugger: ?> gdb $(which gqrx) [lots of text from gdb] (gdb

[Discuss-gnuradio] segfault

Hi to all. This is my first post here...i hope to have choosen the right place to ask I'm currently trying to compile gqrx and gnuradio...everything went well, but when i run gqrx it won't start and give me this error: gqrx[5865]: segfault at 12d0 ip 7f570ee76d2f sp 7fff60fd9000 err

Re: [Discuss-gnuradio] segfault in volk_32f_x2_dot_prod_32f_a_generic

Hi Sergey, the segfault happens in a Volk kernel, which is an optimized numeric algorithm for a length of uniform data. The fact that the base pointer is reachable by gdb but the kernel segfaults somewhere in the middle of operation indicates things are fundamentally wrong with over how much data

[Discuss-gnuradio] segfault in volk_32f_x2_dot_prod_32f_a_generic

Hello and thank you for the gnuradio project! Seems like this mailing list silently drops the messages from non-subscribers, that is not mentioned in . I'm trying to use an AM Demod block but encounter a segfault:

Re: [Discuss-gnuradio] Segfault in analog.quadrature_demod_cf

On Sun, Feb 16, 2014 at 2:52 PM, Matt Mills wrote: > Application that reproduces segfault: > > http://pastebin.com/Fw0y7qM9 > > debug backtrace: http://pastebin.com/FjnHu6Cs > > patch that fixes it for me, although I'm sure theres a better place to fix > it: http://pastebin.com/4gSW57Wt > > Thank

[Discuss-gnuradio] Segfault in analog.quadrature_demod_cf

Application that reproduces segfault: http://pastebin.com/Fw0y7qM9 debug backtrace: http://pastebin.com/FjnHu6Cs patch that fixes it for me, although I'm sure theres a better place to fix it: http://pastebin.com/4gSW57Wt Thanks, Matt. ___ Discuss-gnu

Re: [Discuss-gnuradio] Segfault when running gnuradio-companion

On 06/29/2013 07:21 PM, Liang Xian Loong wrote: I'm using x86 32-bit platform. How can I build/install GNU Radio properly? Thanks. http://www.sbrac.org/files/build-gnuradio may help ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org htt

Re: [Discuss-gnuradio] Segfault when running gnuradio-companion

I'm using x86 32-bit platform. How can I build/install GNU Radio properly? Thanks. On Sun, Jun 30, 2013 at 6:59 AM, Marcus D. Leech wrote: > On 06/29/2013 06:37 PM, Liang Xian Loong wrote: > > Greetings, > > I have installed GNU Radio 3.6.4.1 in Ubuntu 13.04. I have segfaults > when trying

Re: [Discuss-gnuradio] Segfault when running gnuradio-companion

On 06/29/2013 06:37 PM, Liang Xian Loong wrote: Greetings, I have installed GNU Radio 3.6.4.1 in Ubuntu 13.04. I have segfaults when trying to run gnuradio-companion. *$ gnuradio-companion * *linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.003-78-g49a4929b* * * *Segmentation fault (co

[Discuss-gnuradio] Segfault when running gnuradio-companion

Greetings, I have installed GNU Radio 3.6.4.1 in Ubuntu 13.04. I have segfaults when trying to run gnuradio-companion. *$ gnuradio-companion * *linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.003-78-g49a4929b* * * *Segmentation fault (core dumped)* How can I approach this? Thank you. -

Re: [Discuss-gnuradio] segfault: __convert_sc16_item16_usrp1_1_fc32_2_PRIORITY_GENERAL::operator()

On 03/07/2013 01:34 PM, ikjtel wrote: > Okay, so was in zombie mode when I typed the command, but certainly was not > expecting to get a segmentation fault. > > > The failing command was >/usr/bin/python /usr/local/bin/uhd_fft --spec 'A:0 B:0' -f 924e6 > > Things worked fine with --spec

[Discuss-gnuradio] segfault: __convert_sc16_item16_usrp1_1_fc32_2_PRIORITY_GENERAL::operator()

Okay, so was in zombie mode when I typed the command, but certainly was not expecting to get a segmentation fault.  The failing command was    /usr/bin/python /usr/local/bin/uhd_fft --spec 'A:0 B:0' -f 924e6 Things worked fine with --spec 'A:0'.  Below is the seg fault, reported in case there

Re: [Discuss-gnuradio] segfault and gr-fcd

Oh, tricky Patrik - Original Message - From: "Alexandru Csete" To: "Patrik Tast" Cc: Sent: Saturday, April 07, 2012 20:37 Subject: Re: [Discuss-gnuradio] segfault and gr-fcd Interesting, because it seems to be the other way around with the funcube dong

Re: [Discuss-gnuradio] segfault and gr-fcd

: "Alexandru Csete" > To: > Sent: Saturday, April 07, 2012 18:20 > Subject: Re: [Discuss-gnuradio] segfault and gr-fcd > > >> On Sat, Apr 7, 2012 at 4:21 PM, Volker Schroer wrote: >>> >>> Hi all, >>> >>> I'm just using t

Re: [Discuss-gnuradio] segfault and gr-fcd

Glad to hear yo have better luck with libusb 1.0.8. Concerning the errors you see, I don't know how severe they are. There are two layers between gr-fcd and libusb and I have knowledge only with the higher levels. Alex On Sat, Apr 7, 2012 at 5:59 PM, Volker Schroer wrote: > Downgrading to libusb

Re: [Discuss-gnuradio] segfault and gr-fcd

ent: Saturday, April 07, 2012 18:20 Subject: Re: [Discuss-gnuradio] segfault and gr-fcd On Sat, Apr 7, 2012 at 4:21 PM, Volker Schroer wrote: Hi all, I'm just using the gr-fcd block with an funcube dongle on a gentoo linux system. When I try to change the frequency of the dongle by an s

Re: [Discuss-gnuradio] segfault and gr-fcd

Downgrading to libusb-1.0.8 solved the problem. I only see some messages like libusb:error [libusb_cancel_transfer] cancel transfer failed error -5 libusb:error [libusb_cancel_transfer] cancel transfer failed error -5 libusb:error [libusb_cancel_transfer] cancel transfer failed error -5 aUaUaUaU

Re: [Discuss-gnuradio] segfault and gr-fcd

Hi Alex, thank you for the quick response. Hi Volker, Although using a slider to tune hardware pll is a bad idea, I don't think the crash you see is because of that. It sounds more like an issue some people have seen on debian with libusb 1.0.9-pre-something Which version of libusb do you have

Re: [Discuss-gnuradio] segfault and gr-fcd

On Sat, Apr 7, 2012 at 4:21 PM, Volker Schroer wrote: > Hi all, > > I'm just using the gr-fcd block with an funcube dongle on a gentoo linux > system. > > When I try to change the frequency of the dongle by an slider I get the > following segfault: > > ... Hi Volker, Although using a slider to t

[Discuss-gnuradio] segfault and gr-fcd

Hi all, I'm just using the gr-fcd block with an funcube dongle on a gentoo linux system. When I try to change the frequency of the dongle by an slider I get the following segfault: [ 633.104902] usb 1-5.1: link qh1-0e01/8801251cba00 start 0 [1/3 us] [ 633.105563] ehci_hcd :00:12.2

Re: [Discuss-gnuradio] Segfault

On Wed, Apr 4, 2012 at 16:04, Stefan Ott wrote: > > Yup, seems your changes helped! Just FYI, the situation doesn't change > regardless of whether I use uhd 3.3.2, 3.4.0, git master or git next. > I'll try to have a closer look at the ioctls (I'm not particularly > good / experienced at this) to s

Re: [Discuss-gnuradio] Segfault

On Wed, Apr 4, 2012 at 15:36, Philip Balister wrote: > On 04/04/2012 05:24 AM, Stefan Ott wrote: >> On Tue, Apr 3, 2012 at 16:12, Stefan Ott wrote: >>> >>> Ah thanks. I just built a new kernel using that patch (i.e. from the >>> e100-3.0-pm-2-bugfixes branch). I hope that was the right one, the >

Re: [Discuss-gnuradio] Segfault

On 04/04/2012 05:24 AM, Stefan Ott wrote: > On Tue, Apr 3, 2012 at 16:12, Stefan Ott wrote: >> >> Ah thanks. I just built a new kernel using that patch (i.e. from the >> e100-3.0-pm-2-bugfixes branch). I hope that was the right one, the >> usrp_e driver looks ok but is only at version 0.2 as oppos

Re: [Discuss-gnuradio] Segfault

On Tue, Apr 3, 2012 at 16:12, Stefan Ott wrote: > > Ah thanks. I just built a new kernel using that patch (i.e. from the > e100-3.0-pm-2-bugfixes branch). I hope that was the right one, the > usrp_e driver looks ok but is only at version 0.2 as opposed to the > one from the e100-3.0-pm-2-fixes-fro

Re: [Discuss-gnuradio] Segfault

On Mon, Apr 2, 2012 at 18:43, Philip Balister wrote: > On 04/02/2012 09:27 AM, Stefan Ott wrote: >> Hey >> >> Just curious, have you had a chance to look at this? >> >> Also, in the meantime I tried using your kernel tree >> (e100-3.0-pm-2-fixes-from-review) which seems to have a newer version >>

Re: [Discuss-gnuradio] Segfault

On 04/02/2012 09:27 AM, Stefan Ott wrote: > Hey > > Just curious, have you had a chance to look at this? > > Also, in the meantime I tried using your kernel tree > (e100-3.0-pm-2-fixes-from-review) which seems to have a newer version > of the usrp_e driver, built with the kernel configuration tha

Re: [Discuss-gnuradio] Segfault

Hey Just curious, have you had a chance to look at this? Also, in the meantime I tried using your kernel tree (e100-3.0-pm-2-fixes-from-review) which seems to have a newer version of the usrp_e driver, built with the kernel configuration that I took from a working USRP image. However, when trying

Re: [Discuss-gnuradio] Segfault

> Oh, interesting. uhd_find_devices works fine but uhd_usrp_probe also > segfaults. I thought that used to run, I'll try again with different > uhd versions and report back. The same thing happens with all versions of UHD that I tried: uhd_find_devices works but uhd_usrp_probe causes a segfault.

Re: [Discuss-gnuradio] segfault in volk_32fc_x2_multiply_32fc_a_sse3 using current master branch

On Wed, Mar 21, 2012 at 2:08 PM, Nick Foster wrote: > On Wed, Mar 21, 2012 at 10:57 AM, Ben Reynwar wrote: >> >> I'm seeing a segfault in volk_32fc_x2_multiply_32fc_a_sse3 and am >> using the current master branch. >> >> It occurs when I connect a gr.multiply_cc to a running flowgraph >> (using t

Re: [Discuss-gnuradio] segfault in volk_32fc_x2_multiply_32fc_a_sse3 using current master branch

On Wed, Mar 21, 2012 at 10:57 AM, Ben Reynwar wrote: > I'm seeing a segfault in volk_32fc_x2_multiply_32fc_a_sse3 and am > using the current master branch. > > It occurs when I connect a gr.multiply_cc to a running flowgraph > (using tb.lock() and tb.unlock()). If the multiply_cc block is > conn

[Discuss-gnuradio] segfault in volk_32fc_x2_multiply_32fc_a_sse3 using current master branch

I'm seeing a segfault in volk_32fc_x2_multiply_32fc_a_sse3 and am using the current master branch. It occurs when I connect a gr.multiply_cc to a running flowgraph (using tb.lock() and tb.unlock()). If the multiply_cc block is connected before the flowgraph starts running then I don't see a segfa

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Tue, Mar 20, 2012 at 2:24 PM, Nick Foster wrote: > On Tue, Mar 20, 2012 at 10:59 AM, Tom Rondeau wrote: > >> On Tue, Mar 20, 2012 at 11:03 AM, Frederick Stevens < >> sk8tesgr...@gmail.com> wrote: >> >>> Tom, et. al. >>> >>> Here is the output from the volk_profile run (see attached). >>> >>>

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Tue, Mar 20, 2012 at 10:59 AM, Tom Rondeau wrote: > On Tue, Mar 20, 2012 at 11:03 AM, Frederick Stevens > wrote: > >> Tom, et. al. >> >> Here is the output from the volk_profile run (see attached). >> >> Cheers, >> >> Fred >> > > Well, Fred, that output looks good. Everything's showing up as

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Tue, Mar 20, 2012 at 11:03 AM, Frederick Stevens wrote: > Tom, et. al. > > Here is the output from the volk_profile run (see attached). > > Cheers, > > Fred > Well, Fred, that output looks good. Everything's showing up as it should. Interesting that it passed this time, but I half expected it

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On 03/20/2012 10:42 AM, Tom Rondeau wrote: Fred, Thanks. Can you get the entire output (in a text file)? There's some information that's printed at the top that's important. Just run it from the command-line and pipe (>) the output into a file. Just because I'm a grumpy old Unix guy from wa

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Tue, Mar 20, 2012 at 10:39 AM, Frederick Stevens wrote: > Tom, > > Output from volk_profile with your patch applied: > > 8 4 8 2040 > 8 4 8 2041 > 8 4 8 2042 > 8 4 8 2043 > 8 4 8 2044 > 8 4 8 2045 > generic completed in 0.02s > orc completed in 0s > offset 4 in1: 0.248167 in2: -0.655651 > offs

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Tom, Output from volk_profile with your patch applied: 8 4 8 2040 8 4 8 2041 8 4 8 2042 8 4 8 2043 8 4 8 2044 8 4 8 2045 generic completed in 0.02s orc completed in 0s offset 4 in1: 0.248167 in2: -0.655651 offset 6 in1: 0.277863 in2: -0.115331 offset 8 in1: 0.41971 in2: -0.133972 offset 10 in1:

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Tom, Thanks for the patch. I've applied it and will test and send more output for you to examine. By the way, thank you for taking a look at this. I am thankful for this project in the first place and appreciate all of the work that goes into FOSS software. Hopefully this issue can be res

Re: [Discuss-gnuradio] Segfault

On 03/19/2012 07:28 AM, Stefan Ott wrote: > On Fri, Mar 16, 2012 at 20:36, Philip Balister wrote: >> On 03/16/2012 03:32 PM, Stefan Ott wrote: >>> On Mar 16, 2012 8:22 PM, "Philip Balister" wrote: > > I had a look and it what I could find out so far is that offset=1276 > and count=1.

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Mon, Mar 19, 2012 at 4:49 PM, Frederick Stevens wrote: > Tom, > > New run using my simple "trace" See attached files. > > Cheers, > > Fred > Fred, A good start. It's only going through half of the data it's supposed before seg faulting, so it's like one of the buffers (probably the bPtr buff

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Tom, New run using my simple "trace" See attached files. Cheers, Fred On 03/19/2012 11:26 AM, Tom Rondeau wrote: On Mon, Mar 19, 2012 at 12:04 PM, Frederick Stevens mailto:sk8tesgr...@gmail.com>> wrote: Tom, See the attached file. I am running volk_profile now. If this is wha

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Mon, Mar 19, 2012 at 12:04 PM, Frederick Stevens wrote: > Tom, > > See the attached file. I am running volk_profile now. If this is what > you need then that is great otherwise I will keep working on this with > whatever suggestions you have. > > > Cheers, > > Fred > That'll be a good start

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Tom, See the attached file. I am running volk_profile now. If this is what you need then that is great otherwise I will keep working on this with whatever suggestions you have. Cheers, Fred On 03/19/2012 08:10 AM, Tom Rondeau wrote: On Sun, Mar 18, 2012 at 8:00 PM, Frederick Stevens mail

Re: [Discuss-gnuradio] Segfault

On Mon, Mar 19, 2012 at 15:11, Philip Balister wrote: > This is really running on the e100? No dual core CPU. On the E110 > I'm skiing at the moment, so not much time to think about this :) Heh, enjoy! -- Stefan Ott Communication and Distributed Systems Institute of Computer Science and Applie

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

I'll give it a try (more than willing) but you will have to point me to the files to insert the debug print statements and the buffers to use as I am very new to c++ and know only enough c code to be dangerous if left to myself. Usually have my nose in some assembler and used to do a lot of fo

Re: [Discuss-gnuradio] Segfault

On Fri, Mar 16, 2012 at 20:36, Philip Balister wrote: > On 03/16/2012 03:32 PM, Stefan Ott wrote: >> On Mar 16, 2012 8:22 PM, "Philip Balister" wrote: I had a look and it what I could find out so far is that offset=1276 and count=1. >>> >>> For the 32 bit or 16 bit read/write ioctl

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Sun, Mar 18, 2012 at 8:00 PM, Frederick Stevens wrote: > Volk_profile ran to completion. I am using the git source tree updated > just before I did the run. I commented out line 38 of volk_profile.cc as > you suggested and ran volk_profile under gdb. The output is in the > attached text fil

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Volk_profile ran to completion. I am using the git source tree updated just before I did the run. I commented out line 38 of volk_profile.cc as you suggested and ran volk_profile under gdb. The output is in the attached text file. I have also attached the generated volk_config from ~/.volk/

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Well, at least for the moment, I have time (looking for employment, etc.). I was considering trying it on another AMD 32 bit machine that I have sitting here with the same version of Slackware on it. It may take me a day or two to bring it up to the same level of software as this one. It's a

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Fri, Mar 16, 2012 at 6:11 PM, Frederick Stevens wrote: > Well, after a few restarts, here is my output. I did a fresh pull from > git because I was getting some errors with missing *.h files in > gruel/src/swig or something like that. Hope this helps! > > > RUN_VOLK_TESTS: volk_32fc_32f_mult

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Well, after a few restarts, here is my output. I did a fresh pull from git because I was getting some errors with missing *.h files in gruel/src/swig or something like that. Hope this helps! RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a Program received signal SIGSEGV, Segmentation fault. 0x

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Fri, Mar 16, 2012 at 3:11 PM, Frederick Stevens wrote: > I've added your suggested changes. It will be an hour or so until > compilation is finished. Slackware CFLAGS or CXXFLAGS are usually -O2 by > default. > > Cheers, > > Fred > Thanks. GNU Radio resets these flag to -O3 right now, though

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

I've added your suggested changes. It will be an hour or so until compilation is finished. Slackware CFLAGS or CXXFLAGS are usually -O2 by default. Cheers, Fred On 03/16/2012 02:09 PM, Tom Rondeau wrote: On Fri, Mar 16, 2012 at 3:03 PM, Frederick Stevens mailto:sk8tesgr...@gmail.com>> wrote

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Fri, Mar 16, 2012 at 3:03 PM, Frederick Stevens wrote: > Here is the gcc info. It will take me a bit to re compile gnuradio but I > will turn on debugging in cmake. > > gcc (GCC) 4.5.2 > Copyright (C) 2010 Free Software Foundation, Inc. > This is free software; see the source for copying cond

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Here is the gcc info. It will take me a bit to re compile gnuradio but I will turn on debugging in cmake. gcc (GCC) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNES

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Is your system a stock slack 13.37 32bits? >> OK, that's weird as hell. That's the generic implementation, which is >> just >> a std::complex multiply in a for loop. Can you give me your gcc version? >> >> --n >> > > > Yep, that shouldn't be a problem. Fred, can you also give us the > backtrace? >

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Fri, Mar 16, 2012 at 2:50 PM, Nick Foster wrote: > On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens > wrote: > >> Rafael, >> >> Here is the output from gdb: >> >> RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a >> >> Program received signal SIGSEGV, Segmentation fault. >> 0xb7f2c6e0 in volk_

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

On Fri, Mar 16, 2012 at 11:42 AM, Frederick Stevens wrote: > Rafael, > > Here is the output from gdb: > > RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a > > Program received signal SIGSEGV, Segmentation fault. > 0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_**generic () > from /home/fred/extras/gnu

Re: [Discuss-gnuradio] Segfault with volk on 32 bit AMD

Rafael, Here is the output from gdb: RUN_VOLK_TESTS: volk_32fc_32f_multiply_32fc_a Program received signal SIGSEGV, Segmentation fault. 0xb7f2c6e0 in volk_32fc_32f_multiply_32fc_a_generic () from /home/fred/extras/gnuradio/gnuradio/build/volk/lib/libvolk.so.0.0.0 Dump of assembler code fo

  1   2   >