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 <address@hidden>
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 file. I have also
attached the generated volk_config from ~/.volk/volk_config.
Thanks. Strange that it's just that kernel, then. Can you
put in some debug lines that will print out the size of the
buffers being used and the 'number' variable in
volk_32fc_x2_multiply_32fc_a when the crash occurs. I just
want to see if the loop is trying to go beyond the bounds of
the arrays.
I noted from running
gnuradio-companion version 3.5.1, (which works) that when I
use a multiply block, this message from python is generated:
./top_block.py
>>> gr_fir_fff: using 3DNow!
but volk_profile does not seem to recognize the 3DNow!
processor extensions (produces sse2 and sse3 messages on the
Intel Atom 32 bit machine).
Yeah, that's fine. Without a 3DNow! kernel, Volk will just
fall back on the generic implementation. The thought being
that the generic version will work for everyone. So we need to
figure out why that's not true for your...
Hope this helps! Let
me know if you want me to try anything else. I'll let you
know how things turn out on the other machine as well.
Cheers,
Fred
Thanks.
Tom
On 03/18/2012 04:31 PM, Tom Rondeau wrote:
On Fri, Mar 16, 2012 at 6:11
PM, Frederick Stevens <address@hidden>
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_multiply_32fc_a
Program received signal SIGSEGV, Segmentation
fault.
0xb7edbb74 in
volk_32fc_32f_multiply_32fc_a_generic
(cVector=0xb7448008,
aVector=0xb7768008, bVector=0xb78f8008,
num_points=204600)
at
/home/fred/extras/gnuradio/gnuradio/volk/include/volk/volk_32fc_32f_multiply_32fc_a.h:74
74 *cPtr++ = (*aPtr++) * (*bPtr++);
(gdb) bt
#0 0xb7edbb74 in
volk_32fc_32f_multiply_32fc_a_generic
(cVector=0xb7448008,
aVector=0xb7768008, bVector=0xb78f8008,
num_points=204600)
at
/home/fred/extras/gnuradio/gnuradio/volk/include/volk/volk_32fc_32f_multiply_32fc_a.h:74
Alright, Fred, definitely something strange
going on here. My only guess is that for some
reason on your architecture/OS/whatever, something
is being handled incorrectly and the buffers a, b,
and c are not getting generated correctly, maybe
something like it's not doubling the number of
items for the complex data type (before this
function test, there are 16ic, or complex shorts,
being tested, but this is the first complex float
test).
It's hard to tell if it's something about it
being an AMD chip, 32-bit, Slackware version, gcc
version, etc. And I don't have an AMD chip to test
on, but I could load up a 32-bit Slackware VM at
least.
How much work are you willing to put into this
to help us nail this down?
If you can follow through the volk_profile test
code, we can start outputting more debug info. To
start with, I'd suggest going into
volk/apps/volk_profile.cc and commenting out line
38, rebuild the application, and run this new
volk_profile to see if it fails on any other
kernels.
Thanks,
Tom
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|