|
From: | West, Nathan |
Subject: | Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx |
Date: | Wed, 7 Dec 2016 12:10:48 -0500 |
Some sanity appears!From what I can tell, count is keeping track of how many input samples have been processed, which can never be 0. My proposed fix would be to clamp count to 0 somewhere after line 462, but it would be nice for someone to confirm this makes sense.NathanOn Wed, Dec 7, 2016 at 10:18 AM, devin kelly <address@hidden> wrote:I rebuilt GR with CMAKE_BUILD_TYPE=Debug. The al and ar vairables got optimized out, what's the compiler option to prevent that?Looking here (on frame 2 in gdb):
I think I've found part of the problem:This is the line where filter is called (which is where the segfault occurs):d_filters[d_filtnum]->filter(&in[count+d_out_idx]) From GDB I can seed_filtnum = 0
count = -67108696
d_out_idx = 0
(gdb) bt
#0 0x00007fedd163e77f in volk_32fc_32f_dot_prod_32fc_generic (result=0x539eb40, input=0x7fed94b925a0, taps=0x53bb9a0, num_points=45) at /local_disk/spectrum_challenge _src/volk/kernels/volk/volk_ 32fc_32f_dot_prod_32fc.h:83
#1 0x00007fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter(std::complex< float> const*) (this=0x53af290, address@hidden a0) at /local_disk/spectrum_challenge _src/gnuradio/gr-filter/lib/ fir_filter.cc:232
#2 0x00007fedbe22e041 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*> >&) (this=
0x53a1800, noutput_items=256, ninput_items=..., input_items=..., output_items=std::vector of length 1, capacity 1 = {...})
at /local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/ pfb_clock_sync_ccf_impl.cc:465
#3 0x00007fedd1bbdd17 in gr::block_executor::run_one_iteration() (address@hidden 0)
at /local_disk/spectrum_challenge_src/gnuradio/gnuradio- runtime/lib/block_executor.cc: 451
#4 0x00007fedd1bfc6aa in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr:: block>, int) (this=0x7fedafffedb0, block=..., max_noutput_items=<optimized out>)
at /local_disk/spectrum_challenge_src/gnuradio/gnuradio- runtime/lib/tpb_thread_body. cc:122
#5 0x00007fedd1bf0ed1 in boost::detail::function::void_function_obj_invoker0<gr::thre ad::thread_body_wrapper<gr:: tpb_container>, void>::invoke(boost::detail::f unction::function_buffer&) (this=0x53ddc90, this=<optimized out>)
at /local_disk/spectrum_challenge_src/gnuradio/gnuradio- runtime/lib/scheduler_tpb.cc: 44
#6 0x00007fedd1bf0ed1 in boost::detail::function::void_function_obj_invoker0<gr::thre ad::thread_body_wrapper<gr:: tpb_container>, void>::invoke(boost::detail::f unction::function_buffer&) (this=0x53ddc90)
at /local_disk/spectrum_challenge_src/gnuradio/gnuradio- runtime/include/gnuradio/ thread/thread_body_wrapper.h: 51
#7 0x00007fedd1bf0ed1 in boost::detail::function::void_function_obj_invoker0<gr::thre ad::thread_body_wrapper<gr:: tpb_container>, void>::invoke(boost::detail::f unction::function_buffer&) (function_obj_ptr=...)
at /usr/include/boost/function/function_template.hpp:153
#8 0x00007fedd1ba5050 in boost::detail::thread_data<boost::function0<void> >::run() (this=<optimized out>)
at /usr/include/boost/function/function_template.hpp:767
#9 0x00007fedd1ba5050 in boost::detail::thread_data<boost::function0<void> >::run() (this=<optimized out>)
at /usr/include/boost/thread/detail/thread.hpp:117
#10 0x00007fedd06a527a in thread_proxy () at /lib64/libboost_thread-mt.so.1.53.0
#11 0x00007fedec395dc5 in start_thread () at /lib64/libpthread.so.0
#12 0x00007fedeb9bb73d in clone () at /lib64/libc.so.6
(gdb) f 1
#1 0x00007fedbdedcc3f in gr::filter::kernel::fir_filter_ccf::filter (this=0x53af290, address@hidden a0)
at /local_disk/spectrum_challenge_src/gnuradio/gr-filter/lib/ fir_filter.cc:232
232(d_ntaps+al));
(gdb) info locals
ar = <optimized out>
al = <optimized out>
(gdb) print d_ntaps
$1 = 45
(gdb) print al
$2 = <optimized out>
(gdb) print d_aligned_taps[al]
value has been optimized out
(gdb) print d_aligned_taps[0]
$3 = (float *) 0x53bb9a0
(gdb) print d_aligned_taps[1]
$4 = (float *) 0x53bbac0
(gdb) print input
$5 = (const gr_complex *) 0x7fed94b925a0
(gdb) print *input
Cannot access memory at address 0x7fed94b925a0
(gdb) print real(*input)
No symbol "real" in current context.
(gdb) print ar
$6 = <optimized out>
(gdb) f 2
#2 0x00007fedbe22e041 in gr::digital::pfb_clock_sync_ccf_impl::general_work (this=0x53a1800, noutput_items=256,
ninput_items=..., input_items=..., output_items=std::vector of length 1, capacity 1 = {...})
at /local_disk/spectrum_challenge_src/gnuradio/gr-digital/lib/ pfb_clock_sync_ccf_impl.cc:465
465 out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]); (gdb) print d_filtnum
$7 = 0
(gdb) print count
$8 = -67108696
(gdb) print d_out_idx
$9 = 0
(gdb) print in
$10 = (gr_complex *) 0x7fedb4b92060
(gdb) print count+d_out_idx
$11 = -67108696
(gdb) in[count+d_out_idx]
Ambiguous command "in[count+d_out_idx]": .
(gdb) print in[count+d_out_idx]
Cannot access memory at address 0x7fed94b925a0On Tue, Dec 6, 2016 at 2:04 PM, Marcus Müller <address@hidden> wrote:Hi,
hm, you're right, the only way that can happen is if either the input or the tap pointers are invalid; strange.
Since the line in question,
465 out[i+d_out_idx] = d_filters[d_filtnum]->filter(&in[count+d_out_idx]);
in pfb_clock_sync_ccf.cc isn't all that suspicious, let's harass GDB for a moment.
1. since you're in stack frame #0 by default, can you see whether you can `print number` from the gdb shell? It's possible that GCC optimized that variable away, so try `print bPtr`, too.
2. From 1. we know whether this happens on the first loop iteration or a subsequent one; that will show in which direction we'd look for bugs
3. `frame 1` brings us into the context of the fir_filter_ccf::filter function. `print al` and `print d_ntaps`, please!
4. We're getting a bit fancy here with gdb, but whatever :) `print d_aligned_taps[al]`
Hope this gives us a push forward!
Greetings,
Marcus
On 12/06/2016 07:24 PM, devin kelly wrote:
I changed my volk_config like so
volk_32fc_32f_dot_prod_32fc generic generic
And I still get a segfault:
gdb python core.8035
.....
Program terminated with signal 11, Segmentation fault.
#0 0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860,
num_points=45) at /local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32 fc_32f_dot_prod_32fc.h:83
83 *realpt += ((*aPtr++) * (*bPtr));
Missing separate debuginfos, use: debuginfo-install python-2.7.5-48.el7.x86_64
(gdb) bt
#0 0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at /local_disk/spectrum_challenge _src/volk/kernels/volk/volk_32 fc_32f_dot_prod_32fc.h:83
#1 0x00007f114ffff74f in gr::filter::kernel::fir_filter_ccf::filter(std::complex<floa t> const*) ()
at /local_disk/spectrum_challenge/lib64/libgnuradio-filter-3.7. 10.1.so.0.0.0
#2 0x00007f1150356b41 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/spectrum_challenge/lib64/libgnuradio-digital-3.7 .10.1.so.0.0.0
#3 0x00007f1163d14d80 in gr::block_executor::run_one_iteration() ()
at /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7 .10.1.so.0.0.0
#4 0x00007f1163d56090 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr::b lock>, int) ()
at /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7 .10.1.so.0.0.0
#5 0x00007f1163d49791 in boost::detail::function::void_function_obj_invoker0<gr::thre ad::thread_body_wrapper<gr::tp b_container>, void>::invoke(boost::detail::f unction::function_buffer&) ()
at /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7 .10.1.so.0.0.0
#6 0x00007f1163cfae60 in boost::detail::thread_data<boost::function0<void> >::run() ()
at /local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7 .10.1.so.0.0.0
#7 0x00007f11627f927a in thread_proxy () at /lib64/libboost_thread-mt.so.1.53.0
#8 0x00007f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
#9 0x00007f117dafe73d in clone () at /lib64/libc.so.6
(gdb) f 0
#0 0x00007f116379277f in volk_32fc_32f_dot_prod_32fc_generic (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at /local_disk/spectrum_challenge _src/volk/kernels/volk/volk_32 fc_32f_dot_prod_32fc.h:83
83 *realpt += ((*aPtr++) * (*bPtr));
(gdb) info locals
res = {0, 0}
realpt = 0x7f114680f570
imagpt = 0x7f114680f574
aPtr = 0x7f1126cac684
bPtr = 0x56ea860
number = 0
(gdb) print realpt
$1 = (float *) 0x7f114680f570
(gdb) print *realpt
$2 = 0
(gdb) print aPtr
$3 = (const float *) 0x7f1126cac684
(gdb) print *aPtr
Cannot access memory at address 0x7f1126cac684
(gdb) print bPtr
$4 = (const float *) 0x56ea860
(gdb) print *bPtr
$5 = 0.000685208186
The fault happens here:
Since aPtr is just
const float* aPtr = (float*)input;
Maybe the issue is with pfb_clock_sync_ccf_impl? I'm not sure.
Devin
On Tue, Dec 6, 2016 at 1:06 PM, devin kelly <address@hidden> wrote:
It's a bit of both. The segfault usually happens on packet between packets 2 and 3 (I send one packet per second on my transmitter) but sometimes will happen a few packets later. It also always segfaults, I've gotten it to segfault about 20 times or so.
On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan <address@hidden> wrote:
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_t uning
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 <address@hidden> 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_m mx_orc;sse4_2_64_mmx_orc;avx_6 4_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_m mx_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 <address@hidden> 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:
DevinI 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.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.
On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller <address@hidden> 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:
It looks like aPtr (0x7fea5c3014c0) is somehow not valid. GR passes this pointer to VOLK so maybe it's a GR problem?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#L11 9
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:8 35
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:8 35
#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/vo lk/kernels/volk/volk_32fc_32f_ dot_prod_32fc.h:119
#2 0x00007fea6661d88f in gr::filter::kernel::fir_filter_ccf::filter(std::complex<floa t> 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.s o.0.0.0
#5 0x00007fea7b781120 in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr<gr::b lock>, int) () at /local_disk/gr_3.7.10.1/lib64/ libgnuradio-runtime-3.7.10.1.s o.0.0.0
#6 0x00007fea7b774821 in boost::detail::function::void_function_obj_invoker0<gr::thre ad::thread_body_wrapper<gr::tp b_container>, void>::invoke(boost::detail::f unction::function_buffer&) () at /local_disk/gr_3.7.10.1/lib64/ libgnuradio-runtime-3.7.10.1.s o.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.s o.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/vo lk/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 list address@hidden https://lists.gnu.org/mailman/ listinfo/discuss-gnuradio _________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/ listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/ listinfo/discuss-gnuradio _________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/ listinfo/discuss-gnuradio _________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/ listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/ listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |