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 resolved. I still need to test this on my other system but finding
work is a priority right now.
Got this error when applying the patch. I will try it manually (patch
-pX < ../location_to_diff sort of thing) and see what happens.
git apply ../volk_slackware32.diff
../volk_slackware32.diff:13: trailing whitespace.
/*
warning: 1 line adds whitespace errors.
Cheers,
Fred
On 03/20/2012 08:49 AM, Tom Rondeau wrote:
On Mon, Mar 19, 2012 at 4:49 PM, Frederick Stevens
<sk8tesgr...@gmail.com <mailto:sk8tesgr...@gmail.com>> 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 buffer to the 32f input) isn't getting allocated properly.
I've attached a patch that only tests this kernel so no other outputs
will confuse things and I've shortened the run length (single
iteration, fewer samples). This now spits out the data used to
generate the input and output buffers. It also outputs the size of the
data types in the test instead of the pointer size.
if you're unfamiliar with working with patches, just reset your git
tree (git reset --hard, unless you have some changes you need to /
want to keep) and apply this (git apply
location/volk_slackware32.diff). I suggest the reset so there aren't
any conflicts or problems when applying.
Thanks,
Tom
On 03/19/2012 11:26 AM, Tom Rondeau wrote:
On Mon, Mar 19, 2012 at 12:04 PM, Frederick Stevens
<sk8tesgr...@gmail.com <mailto:sk8tesgr...@gmail.com>> 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. We'll see if that tells us anything.
Thanks,
Tom
On 03/19/2012 08:10 AM, Tom Rondeau wrote:
On Sun, Mar 18, 2012 at 8:00 PM, Frederick Stevens
<sk8tesgr...@gmail.com <mailto:sk8tesgr...@gmail.com>> 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
<sk8tesgr...@gmail.com <mailto:sk8tesgr...@gmail.com>>
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
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
_______________________________________________
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
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
