On Tue, Mar 20, 2012 at 11:03 AM, Frederick Stevens <[email protected]>wrote:
> Tom, et. al. > > Here is the output from the volk_profile run (see attached). > > Cheers, > > Fred > Well, Fred, that output looks good. Everything's showing up as it should. Interesting that it passed this time, but I half expected it to. It seems like there's a memory allocation problem going on, since when it crashes, it did so just a bit after getting half way through, must have been when it hit something else allocated. Very odd behavior that I've seen on occasion, but they way the memory is allocated in the volk_qa_aligned_mem_pool, I wouldn't expect there to be a problem. Right now, I'm at a loss on how to proceed. I can't think of any more really useful tests. Were I able to reproduce this error on one of my machines, I'd just have to start tinkering around and getting more output data. Tom > On 03/20/2012 09:47 AM, Marcus D. Leech wrote: > > 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 <[email protected] >> > 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 >>>>> [email protected] >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org > > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
