Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but that's a separate topic.
You can configure VOLK to not use this protokernel and there's some documentation on how to do it here: http://gnuradio.org/doc/doxygen/volk_guide.html#volk_tuning This is fairly concerning though... are you able to consistently trigger a segfault or is it a seemingly random event that you can't trigger? On Tue, Dec 6, 2016 at 11:48 AM, devin kelly <dwwke...@gmail.com> wrote: > OK, I tried a brand new GR/Volk install and still had the same problem. > So no problem with re-linking Volk to GR. Could this be an issue with Volk > on GCC 4.8.5? The newest GCC is 6.2 so 4.8.5 is pretty old, though the > newest for Red Hat 7. Is there any way to reconfigure volk to not use > volk_32fc_32f_dot_prod_32fc_a_avx? > > Here's volk-config-info: > > $ volk-config-info --all --prefix --cc --cflags --avail-machines --machine > --alignment --malloc > /local_disk/spectrum_challenge > cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11) > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software see the source for copying conditions. There is NO > warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > /usr/bin/cc::: -Wall > /usr/bin/c++::: -Wall > generic_orc:::GNU:::-g -Wall > sse2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 > sse3_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 > ssse3_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3 > sse4_a_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -msse4a > -mpopcnt > sse4_1_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3 > -msse4.1 > sse4_2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3 > -msse4.1 -msse4.2 -mpopcnt > avx_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3 > -msse4.1 -msse4.2 -mpopcnt -mavx > avx2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3 > -msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2 > generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_ > orc;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc; > avx_64_mmx_orc;avx2_64_mmx_orc; > generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_ > orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc; > avx2_64_mmx_orc > Alignment in bytes: 32 > Used malloc implementation: posix_memalign > > > Thanks again for any help, > Devin > > > On Fri, Dec 2, 2016 at 10:04 AM, Marcus Müller <marcus.muel...@ettus.com> > wrote: > >> Oh, that's pretty interesting! Well, no misconfiguration should segfault, >> so I'm a bit stumped at the moment. >> >> On 12/01/2016 06:14 PM, devin kelly wrote: >> >> Marcus, >> >> Thanks for taking the time. It is possible I re-installed a new version >> of VOLK. I'll try a fresh build and see what that gets me. >> >> I also should have mentioned that the filter works OK for a while then >> segfaults. A couple of packets always pass through the clock sync block >> I'm using before I get the segfault. Finally, the segfault occurs in the >> polyphase clock sync block, do you think I could have mis-configured the >> block in some way that will get me this error? I think the PF clock sync >> block is pretty popular so if there's a bug in that block that's causing >> this I'd be surprised. >> >> Devin >> >> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller <marcus.muel...@ettus.com> >> wrote: >> >>> Hi Devin, >>> >>> I don't think it's a kernel problem – all your calculations happen in >>> userland, and the kernel has not much to say with respect to the >>> instructions used. >>> >>> The most common reason for this kind of misbehaviour is in fact a >>> problem with how the application (in this case, your GNU Radio >>> application's block) calls into the library function (in this case the VOLK >>> dot product). >>> >>> Is it possible that for some reason, GNU Radio used a previous version >>> of VOLK when you linked it, and then the new version of VOLK was installed? >>> >>> Best regards, >>> >>> Marcus >>> >>> On 12/01/2016 05:23 PM, devin kelly wrote: >>> >>> Hello, >>> >>> I'm having a problem with the above VOLK function segfaulting. I don't >>> think I'm passing any incorrect values to VOLK. My problem could be that >>> I'm on RHEL7 with (obviously) an older kernel: >>> >>> $ uname -a >>> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55 >>> EST 2016 x86_64 x86_64 x86_64 GNU/Linux >>> >>> I'm on VOLK 1.3 and GR 3.7.10.1. >>> >>> it segfaults here: >>> https://github.com/gnuradio/volk/blob/maint/kernels/volk/vol >>> k_32fc_32f_dot_prod_32fc.h#L119 >>> It looks like aPtr (0x7fea5c3014c0) is somehow not valid. GR passes >>> this pointer to VOLK so maybe it's a GR problem? >>> >>> I've copied the output of a GDB session and my CPU info below. >>> >>> Thanks for any help, >>> Devin >>> >>> >>> >>> Program terminated with signal 11, Segmentation fault. >>> #0 0x00007fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at >>> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835 >>> 835 return *(__m256 *)__P; >>> Missing separate debuginfos, use: debuginfo-install >>> python-2.7.5-48.el7.x86_64 >>> (gdb) bt >>> #0 0x00007fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx >>> (__P=0x7fea5c3014c0) at /usr/lib/gcc/x86_64-redhat-lin >>> ux/4.8.5/include/avxintrin.h:835 >>> #1 0x00007fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx >>> (result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at >>> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_ >>> dot_prod_32fc.h:119 >>> #2 0x00007fea6661d88f in gr::filter::kernel::fir_filter >>> _ccf::filter(std::complex<float> const*) () at >>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0 >>> #3 0x00007fea66c01d01 in >>> gr::digital::pfb_clock_sync_ccf_impl::general_work(int, >>> std::vector<int, std::allocator<int> >&, std::vector<void const*, >>> std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >>> >&) () >>> at /local_disk/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.s >>> o.0.0.0 >>> #4 0x00007fea7b73fe10 in gr::block_executor::run_one_iteration() () at >>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0 >>> #5 0x00007fea7b781120 in gr::tpb_thread_body::tpb_threa >>> d_body(boost::shared_ptr<gr::block>, int) () at >>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0 >>> #6 0x00007fea7b774821 in boost::detail::function::void_ >>> function_obj_invoker0<gr::thread::thread_body_wrapper<gr::tpb_container>, >>> void>::invoke(boost::detail::function::function_buffer&) () at >>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0 >>> #7 0x00007fea7b725ef0 in boost::detail::thread_data<boost::function0<void> >>> >::run() () at /local_disk/gr_3.7.10.1/lib64/ >>> libgnuradio-runtime-3.7.10.1.so.0.0.0 >>> #8 0x00007fea7a22427a in thread_proxy () at >>> /lib64/libboost_thread-mt.so.1.53.0 >>> #9 0x00007fea960f3dc5 in start_thread () at /lib64/libpthread.so.0 >>> #10 0x00007fea9571973d in clone () at /lib64/libc.so.6 >>> (gdb) print __P >>> $1 = (const float *) 0x7fea5c3014c0 >>> (gdb) print *__P >>> Cannot access memory at address 0x7fea5c3014c0 >>> (gdb) print *(__m256 *)__P >>> Cannot access memory at address 0x7fea5c3014c0 >>> (gdb) f 1 >>> #1 volk_32fc_32f_dot_prod_32fc_a_avx (result=0x3665160, >>> input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at >>> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_ >>> dot_prod_32fc.h:119 >>> 119 a0Val = _mm256_load_ps(aPtr); >>> (gdb) info locals >>> number = 0 >>> sixteenthPoints = 2 >>> res = {-1.30492652e+29, 0.0779444203} >>> realpt = 0x7fea57ffde50 >>> imagpt = 0x7fea57ffde54 >>> aPtr = 0x7fea5c3014c0 >>> bPtr = 0x3671a00 >>> a0Val = {-0.656753004, -0.658071458, -0.760932922, -0.762304127, >>> -0.869615495, -0.869560063, -0.887507021, -0.885902643} >>> a1Val = {-0.744178772, -0.742508531, -0.437728733, -0.437706977, >>> -0.0328192525, -0.0346645005, 0.376206338, 0.374125361} >>> a2Val = {0.711783648, 0.711464763, 0.931477308, 0.933318734, 1.01744843, >>> 1.01973152, 0.954917312, 0.955377996} >>> a3Val = {0.734342158, 0.732418418, 0.374049634, 0.371605545, >>> -0.0585254543, -0.0588675328, -0.461206883, -0.458686352} >>> b0Val = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694, >>> 0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293} >>> b1Val = {-0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193, >>> 0.0485430211, 0.0485430211, -0.22138992, -0.22138992} >>> b2Val = {0, 0, 0.22138992, 0.22138992, -0.0485430211, -0.0485430211, >>> -0.00614725193, -0.00614725193} >>> b3Val = {0.0158917159, 0.0158917159, -0.00727195293, -0.00727195293, >>> -0.00242348039, -0.00242348039, 0.00534401694, 0.00534401694} >>> x0Val = {0.0023738991, -0.00534401694, 0.00242348039, 0.00727195293, >>> -0.0158917159, 0.00614725193, 0.0485430211, -0.22138992} >>> x1Val = {0, 0.22138992, -0.0485430211, -0.00614725193, 0.0158917159, >>> -0.00727195293, -0.00242348039, 0.00534401694} >>> x0loVal = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694, >>> -0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193} >>> x0hiVal = {0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293, >>> 0.0485430211, 0.0485430211, -0.22138992, -0.22138992} >>> x1loVal = {0, 0, 0.22138992, 0.22138992, 0.0158917159, 0.0158917159, >>> -0.00727195293, -0.00727195293} >>> x1hiVal = {-0.0485430211, -0.0485430211, -0.00614725193, -0.00614725193, >>> -0.00242348039, -0.00242348039, 0.00534401694, 0.00534401694} >>> c0Val = {-0.00155906542, -0.00156219525, 0.00406643841, 0.00407376606, >>> -0.00210749614, -0.0021073618, -0.00645390945, -0.0064422423} >>> c1Val = {0.0118262777, 0.011799735, -0.00269082887, -0.00269069499, >>> -0.00159314566, -0.00168271956, -0.0832882896, -0.082827583} >>> c2Val = {0, 0, 0.206219688, 0.206627354, -0.0493900217, -0.0495008491, >>> -0.00587011734, -0.00587294903} >>> c3Val = {0.0116699571, 0.0116393855, -0.00272007124, -0.00270229811, >>> 0.000141835291, 0.000142664314, -0.00246469746, -0.00245122775} >>> dotProdVal0 = {0, 0, 0, 0, 0, 0, 0, 0} >>> dotProdVal1 = {0, 0, 0, 0, 0, 0, 0, 0} >>> dotProdVal2 = {0, 0, 0, 0, 0, 0, 0, 0} >>> dotProdVal3 = {0, 0, 0, 0, 0, 0, 0, 0} >>> dotProductVector = {0.0218032673, 0.0217418969, 0.204074427, >>> 0.204509094, -0.0519821495, -0.0521854945, -0.0983558819, -0.097870864} >>> (gdb) print *aPtr >>> Cannot access memory at address 0x7fea5c3014c0 >>> >>> >>> >>> >>> $ lscpu >>> Architecture: x86_64 >>> CPU op-mode(s): 32-bit, 64-bit >>> Byte Order: Little Endian >>> CPU(s): 4 >>> On-line CPU(s) list: 0-3 >>> Thread(s) per core: 2 >>> Core(s) per socket: 2 >>> Socket(s): 1 >>> NUMA node(s): 1 >>> Vendor ID: GenuineIntel >>> CPU family: 6 >>> Model: 61 >>> Model name: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz >>> Stepping: 4 >>> CPU MHz: 2038.664 >>> BogoMIPS: 5187.61 >>> Virtualization: VT-x >>> L1d cache: 32K >>> L1i cache: 32K >>> L2 cache: 256K >>> L3 cache: 4096K >>> NUMA node0 CPU(s): 0-3 >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing >>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> _______________________________________________ Discuss-gnuradio >>> mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/ >>> listinfo/discuss-gnuradio >> >> _______________________________________________ >> Discuss-gnuradio mailing >> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> 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 > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
