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
<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 <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
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
