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.
<pedantic>
Just because I'm a grumpy old Unix guy from waaaaay back, I'll point
out that the term "pipe" is very frequently mis-used to mean
"redirect", when in fact, the pipe symbol in the Unix shell is "|"
and is a mechanism for attaching the standard output of one program
to the standard input of another. The ">" symbol means
"redirect the standard output to a file", which is similar, but not
the same as,
the use of a "pipe", which is an IPC mechanism.
</pedantic>
Oh, and that trailing whitespace warning shouldn't be a
problem. The patch should have still be applied.
Thanks,
Tom
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
_______________________________________________
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
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
|