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