Install: qa_volk_test_all fails on armv7

The volk test is failing on my gnuradio build on a Beaglebone Black
(armv7h) running Arch Linux Arm.

Configuration that failed to enable:
gr-ctrlport *** disabled [do i need this?]
gr-comedi *** disabled [don’t need]
gr-qtgui *** disabled [don’t need]
gr-documentation *** disabled [don’t need]

make test

start 1: qa_volk_test_all
*** 2 failures detected in test suite "Master Test Suite"1/177 Test
#1:
qa_volk_test_all …***Failed 9.88 sec

ctest -V -R qa_volk_test_all | grep error

1: /root/build/gnuradio-git/src/gnuradio/volk/lib/testqa.cc(10): error
in
“volk_16ic_s32f_deinterleave_32f_x2_test”: check
run_volk_tests(volk_16ic_s32f_deinterleave_32f_x2_get_func_desc(), (void
(*)())volk_16ic_s32f_deinterleave_32f_x2_manual,
std::string(“volk_16ic_s32f_deinterleave_32f_x2”), 1e-4, 32768.0, 20462,
1,
0, “NULL”) == 0 failed [true != 0]

1: /root/build/gnuradio-git/src/gnuradio/volk/lib/testqa.cc(39): error
in
“volk_32fc_s32f_magnitude_16i_test”: check
run_volk_tests(volk_32fc_s32f_magnitude_16i_get_func_desc(), (void
(*)())volk_32fc_s32f_magnitude_16i_manual,
std::string(“volk_32fc_s32f_magnitude_16i”), 1, 32768, 20462, 1, 0,
“NULL”)
== 0 failed [true != 0]

Full output of ctest -V _R qa_volk_test_all is attatched.

I’m not really sure how to go from here to diagnose the problem. I’m
building the latest gnuradio git source (packaged by the AUR) on the
beagle
bone black via distcc which is cross compiling on my x86_64 desktop with
the same toolchain.

Any advice?

As far as configuration these failed to get enabled:

On Tue, Nov 26, 2013 at 10:38 AM, Ken A. [email protected] wrote:

make test

std::string(“volk_16ic_s32f_deinterleave_32f_x2”), 1e-4, 32768.0, 20462, 1,

I’m not really sure how to go from here to diagnose the problem. I’m
building the latest gnuradio git source (packaged by the AUR) on the beagle
bone black via distcc which is cross compiling on my x86_64 desktop with the
same toolchain.

Any advice?

As far as configuration these failed to get enabled:

which version of GNU Radio? These bugs were fixed on Nov. 19 and will
be a part of the 3.7.2.1 release. See bugs #582 and #583 on our Issues
page.

Tom

The volk test is failing on my gnuradio build on a Beaglebone Black
(armv7h) running Arch Linux Arm.

make test

start 1: qa_volk_test_all
*** 2 failures detected in test suite "Master Test Suite"1/177 Test #1:
qa_volk_test_all …***Failed 9.88 sec

Full output of ctest -V _R qa_volk_test_all is attatched.

which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a part
of the 3.7.2.1 release.
See bugs #582 and #583 on our Issues page.
Tom

After pulling the latest GR code (as of Dec 1) and doing a fresh build,
my ARMv7 target’s ctest output for qa_volk_test_all matches what Ken
attached in the first message of this thread. So there is something
still going on here. Is it possible some external component needs to be
updated, that is outside of what’s in the GR git tree?

The output I originally logged in Bug #583 differs from our latest
results, but the behavior is the same (in1/in2 values appear to match).

The output I originally logged in Bug #582 (for ARM target) remains the
same (in1/in2 values differ by 1).

Regards,
Tim

On Tue, Dec 3, 2013 at 3:13 PM, Monahan-Mitchell, Tim
[email protected] wrote:

which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a part
of the 3.7.2.1 release.
Tim
I just did a fresh install on my ARMv7 of the entire OS and GNU Radio
from the latest git checkout (was testing Balister’s new OE manifest
and SDK) and everything is working great here.

When you say you did a “fresh build”, what does that really mean? One
of the quirks of volk is that cmake /has/ to be rerun when these kinds
of changes are made. Best really to clean up everything to make sure
you’re doing everything from a clean checkout. “git reset --hard; git
pull origin master; git clean -dxf;”. Then rerun cmake and make from a
clean build directory.

The above might be overkill, so if you want a quicker test, start with
the clean git pull of the latest head and just make sure to rerun
cmake and make, not necessarily from an empty directory.

Tom

On 12/04/2013 09:45 AM, Tom R. wrote:

Full output of ctest -V _R qa_volk_test_all is attatched.

you’re doing everything from a clean checkout. “git reset --hard; git
pull origin master; git clean -dxf;”. Then rerun cmake and make from a
clean build directory.

The above might be overkill, so if you want a quicker test, start with
the clean git pull of the latest head and just make sure to rerun
cmake and make, not necessarily from an empty directory.

Building gnuradio on an arm is silly :slight_smile: (OK, mayb eif you have an armv8
server, but these do not exists yet) I am building gnuradio on a quad
A15 (limping across the OOM’s). At the same time I built the toolchain
form an imge, installed the toolchain, configured and compiled gnuradio
on my x86.

Once we solve the mystery of the hardcoded paths in the QA code and work
out installing on the target from a cross build, things will be really
nice.

On the subject of the email, I am wondering if the QA failure is relates
to the use of the hard float ABI. I’m switching my OE builds to armthf
now so I can compare my results with Tom’s.

Philip

The volk test is failing on my gnuradio build on a Beaglebone Black
(armv7h) running Arch Linux Arm.

make test

start 1: qa_volk_test_all
*** 2 failures detected in test suite "Master Test Suite"1/177 Test #1:
qa_volk_test_all …***Failed 9.88 sec

Full output of ctest -V _R qa_volk_test_all is attatched.

which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a
part of the 3.7.2.1 release.

See bugs #582 and #583 on our Issues page.
Tom

After pulling the latest GR code (as of Dec 1) and doing a fresh build, my
ARMv7 target’s ctest output for qa_volk_test_all matches what Ken attached in the
first message of this thread. So there is something still going on here. Is it
possible some external component needs to be updated, that is outside of what’s in
the GR git tree?

The output I originally logged in Bug #583 differs from our latest results,
but the behavior is the same (in1/in2 values appear to match).

The output I originally logged in Bug #582 (for ARM target) remains the same
(in1/in2 values differ by 1).

I just did a fresh install on my ARMv7 of the entire OS and GNU Radio
from the latest git checkout (was testing Balister’s new OE manifest
and SDK) and everything is working great here.

When you say you did a “fresh build”, what does that really mean? One
of the quirks of volk is that cmake /has/ to be rerun when these kinds
of changes are made. Best really to clean up everything to make sure
you’re doing everything from a clean checkout. “git reset --hard; git
pull origin master; git clean -dxf;”. Then rerun cmake and make from a
clean build directory.

The above might be overkill, so if you want a quicker test, start with
the clean git pull of the latest head and just make sure to rerun
cmake and make, not necessarily from an empty directory.

Hi, Tom,
I tried these steps:

  • Uninstalled gnuradio (make uninstall).
  • apt-get update + apt-get upgrade for my ARM7 target (Ubuntu 13.04),
    which updated quite a bit of stuff.
  • Deleted my gnuradio tree and re-cloned it.
  • Checkout maint branch.
  • Built as I have been doing.
  • Same problem :frowning:

Hi, Philip,

Building gnuradio on an arm is silly :slight_smile:
I bow to the sheer power of your A15 toolchain-rebuild cross-compile x86
prowess. :slight_smile:

I am wondering if the QA failure is relates, to the use of the hard float ABI.
For me, whenever I have tried to specify hard or soft float ABI, cmake
fails. If I don’t specify it, it just works…

I’m switching my OE builds to armthf now so I can compare my results with Tom’s.
Thanks!

Tim

On 12/04/2013 05:26 PM, Monahan-Mitchell, Tim wrote:

which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a
part of the 3.7.2.1 release.

Hi, Philip,

Building gnuradio on an arm is silly :slight_smile:
I bow to the sheer power of your A15 toolchain-rebuild cross-compile x86
prowess. :slight_smile:

I am wondering if the QA failure is relates, to the use of the hard float ABI.
For me, whenever I have tried to specify hard or soft float ABI, cmake fails. If
I don’t specify it, it just works…

I’m switching my OE builds to armthf now so I can compare my results with
Tom’s.
Thanks!

I’m working on a real fix for the qa code (not just symlinking until it
works) Hopefully, I can confirm hard float status tomorrow.

Philip

On Wed, Dec 4, 2013 at 6:38 PM, Philip B. [email protected]
wrote:

and SDK) and everything is working great here.
cmake and make, not necessarily from an empty directory.

I’m working on a real fix for the qa code (not just symlinking until it
works) Hopefully, I can confirm hard float status tomorrow.

Philip

Seems like Philip was able to replicate these VOLK bugs using the hard
float build. I just tried it myself using his hard float OE, but I’m
still getting everything to pass ok on my system.

Tom

I am wondering if the QA failure is relates, to the use of the hard float
ABI.

For me, whenever I have tried to specify hard or soft float ABI, cmake fails.
If I don’t specify it, it just works…

I’m switching my OE builds to armthf now so I can compare my results with
Tom’s.

I’m working on a real fix for the qa code (not just symlinking until
it works) Hopefully, I can confirm hard float status tomorrow.

Philip

Seems like Philip was able to replicate these VOLK bugs using the hard float
build.
I just tried it myself using his hard float OE, but I’m still getting everything
to pass ok on my system.
Tom

OK, good to hear. Does that mean bugs 582 and 583 should be re-opened?

On Wed, Dec 11, 2013 at 10:35 AM, Monahan-Mitchell, Tim
[email protected] wrote:

Seems like Philip was able to replicate these VOLK bugs using the hard float
build.

I just tried it myself using his hard float OE, but I’m still getting
everything to pass ok on my system.

Tom

OK, good to hear. Does that mean bugs 582 and 583 should be re-opened?

I’ve reopened the tickets as “Works for some”. Philip, Nathan, and I
agreed to work together this week to try to resolve it seeing as how
Philip can replicate the problems.

Weather has delayed my weekend travel plans, so I won’t get home until
late tomorrow night. Hopefully, we can get to this Tuesday or
Wednesday.

Tom

Has there been any progress on this bug?
Would this effect performance enough to cause The under run uUuUuU at
250k
sample rate on a beaglebone black (1ghz arm v7- nothing running)?

On Sun, Dec 15, 2013 at 12:23 PM, Tom R. [email protected] wrote:

On Wed, Dec 11, 2013 at 10:35 AM, Monahan-Mitchell, Tim

OK, good to hear. Does that mean bugs 582 and 583 should be re-opened?

I’ve reopened the tickets as “Works for some”. Philip, Nathan, and I
agreed to work together this week to try to resolve it seeing as how
Philip can replicate the problems.

Just another data point. Similar results here with native A15 build on
Linaro 13.11.

$ make test
Running tests…
Test project /tmp/gnuradio/build
Start 1: qa_volk_test_all
1/1 Test #1: qa_volk_test_all …***Failed 1.88 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) = 1.94 sec

The following tests FAILED:
1 - qa_volk_test_all (Failed)
Errors while running CTest
make: *** [test] Error 8

-TT

Check that you are powered from 5V, otherwise BBB runs at 300 MHz.

On Tue, Jan 14, 2014 at 5:27 PM, Ken A. [email protected] wrote:

Has there been any progress on this bug?

Hi all,

I have a branch that I’d like to get some more data points for before
merging. I think I’ve identified a possibility for the issue and it
might be a compiler bug, but results are somewhat inconclusive. If
you have seen this bug (or even if you haven’t and you want to provide
additional data points) can you test this branch:
https://github.com/n-west/gnuradio/tree/volk-qa-bugfixes

If you can take time to test is, please send back the following data:

  • success or failure of make test
  • architecture (x86, x86_64, arm cortex a9/cortex 15, etc…, also
    include hardfloat or softfloat if ARM). If you’re running in a VM also
    include that.
  • Distribution (if oe specify that)
  • compiler version
  • if you saw failures, please include relevant ctest -V output

I would appreciate reports of success and failures.

Happy hacking,
Nathan

PS-
Tom,
The headaches continue. After you test the previous branch can you
also look at https://github.com/n-west/gnuradio/tree/volk-qa-volk_malloc
Reviewing my malloc/frees in there would be good. This passes QA on my
armv7hf, but fails on my x86_64. Some kernels were actually reported
to be giving incorrect results (http://pastebin.com/VWPtVk4M). This
might suggest it is memory corruption rather than a compiler problem
after all.

Jonathan,
I know this is based off master, but Philip’s stuff in master that
makes cross testing a lot easier. Forgive me this time :slight_smile:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs