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:
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.
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).
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.
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 (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.
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
Hi, Philip,
Building gnuradio on an arm is silly
I bow to the sheer power of your A15 toolchain-rebuild cross-compile x86
prowess.
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!
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
I bow to the sheer power of your A15 toolchain-rebuild cross-compile x86
prowess.
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.
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.
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.
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 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
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
(OK, mayb eif you have an armv8