On Thu, Mar 8, 2012 at 11:16 AM, Tom Rondeau <t...@trondeau.com> wrote:
> On Thu, Mar 8, 2012 at 1:22 PM, Marcus D. Leech <mle...@ripnet.com> wrote: > >> On 08/03/12 01:11 PM, Nick Foster wrote: >> > Rafiq, >> > >> > What CPU are you using for this test? Specifically, please send the >> > output of "cat /proc/cpuinfo". >> > >> > --n >> > >> To add some more data, I tested the attached flow-graph on the only >> remaining 32-bit machine in my herd. >> It provoked: >> >> #0 0x0090d6b3 in volk_32fc_x2_multiply_32fc_a_sse3 () >> from /usr/local/lib/libvolk.so.0.0.0 >> #1 0x008de0d5 in get_volk_32fc_x2_multiply_32fc_a () >> from /usr/local/lib/libvolk.so.0.0.0 >> #2 0x00a8f517 in gri_fft_filter_ccc_generic::filter(int, >> std::complex<float> const*, std::complex<float>*) () >> from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 >> #3 0x00a967fb in gr_fft_filter_ccc::work(int, std::vector<void const*, >> std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >> >&) () >> from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 >> #4 0x00a65eb7 in gr_sync_decimator::general_work(int, std::vector<int, >> std::allocator<int> >&, std::vector<void const*, std::allocator<void >> const*> >&, std::vector<void*, std::allocator<void*> >&) () >> from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 >> #5 0x00a4d185 in gr_block_executor::run_one_iteration() () >> from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 >> #6 0x00a688e3 in >> gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr<gr_block>, int) >> () from /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 >> #7 0x00a62bfc in >> >> boost::detail::function::void_function_obj_invoker0<gruel::thread_body_wrapper<tpb_container>, >> void>::invoke(boost::detail::function::function_buffer&) () from >> /usr/local/lib/libgnuradio-core-3.5.3git.so.0.0.0 >> #8 0x001b881c in boost::function0<void>::operator()() const () >> from /usr/local/lib/libgruel-3.5.3git.so.0.0.0 >> >> >> This is on a Fedora-12 machine, here's /proc/cpuinfo >> >> processor : 0 >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 14 >> model name : Genuine Intel(R) CPU T2400 @ 1.83GHz >> stepping : 8 >> cpu MHz : 1000.000 >> cache size : 2048 KB >> physical id : 0 >> siblings : 2 >> core id : 0 >> cpu cores : 2 >> apicid : 0 >> initial apicid : 0 >> fdiv_bug : no >> hlt_bug : no >> f00f_bug : no >> coma_bug : no >> fpu : yes >> fpu_exception : yes >> cpuid level : 10 >> wp : yes >> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov >> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc >> arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm >> bogomips : 3657.49 >> clflush size : 64 >> cache_alignment : 64 >> address sizes : 32 bits physical, 32 bits virtual >> power management: >> >> processor : 1 >> vendor_id : GenuineIntel >> cpu family : 6 >> model : 14 >> model name : Genuine Intel(R) CPU T2400 @ 1.83GHz >> stepping : 8 >> cpu MHz : 1000.000 >> cache size : 2048 KB >> physical id : 0 >> siblings : 2 >> core id : 1 >> cpu cores : 2 >> apicid : 1 >> initial apicid : 1 >> fdiv_bug : no >> hlt_bug : no >> f00f_bug : no >> coma_bug : no >> fpu : yes >> fpu_exception : yes >> cpuid level : 10 >> wp : yes >> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov >> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc >> arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm >> bogomips : 3657.54 >> clflush size : 64 >> cache_alignment : 64 >> address sizes : 32 bits physical, 32 bits virtual >> power management: > > > > Well, there's your problem right there! > > flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov > clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc > arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm > > Your CPU doesn't seem to support SSE3, which begs the question, why is it > allowed to call the SSE3 proto-kernel? > > Check your ~/.volk/volk_config to see what it says on that kernel (that > is, if you have run volk_profile; if you haven't, run it first and see what > happens). > I'm not wholly convinced this is the problem. I'd expect to see an illegal instruction error, not a memory access error, if an SSE3 instruction were called on a machine which doesn't support it. That said, if SSE3 isn't set in cpuflags it shouldn't be allowed in Volk. I'll check the flag in Volk... --n > > Tom > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
