New run using my simple "trace" See attached files.
On 03/19/2012 11:26 AM, Tom Rondeau wrote:
On Mon, Mar 19, 2012 at 12:04 PM,
Frederick Stevens <address@hidden>
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.
That'll be a good start. We'll see if that tells us
On 03/19/2012 08:10 AM, Tom Rondeau wrote:
On Sun, Mar 18, 2012 at 8:00
PM, Frederick Stevens <address@hidden>
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
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.
from running gnuradio-companion version 3.5.1,
(which works) that when I use a multiply block,
this message from python is generated:
>>> 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...
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.
On 03/18/2012 04:31 PM, Tom Rondeau wrote:
On Fri, Mar 16,
2012 at 6:11 PM, Frederick Stevens <address@hidden>
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!
Program received signal SIGSEGV,
74 *cPtr++ = (*aPtr++) *
#0 0xb7edbb74 in
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
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
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
commenting out line 38, rebuild the
application, and run this new
volk_profile to see if it fails on any
Discuss-gnuradio mailing list
Discuss-gnuradio mailing list