On 04/04/2013 10:22 AM, Brian Tinsley wrote:
> Hello list!
>
> I have a couple of "tiny machines" based on the ARM architecture and
> wanted to see how the Assimilation code would build and run on these
> devices. One is a Raspberry Pi and the other is a Via APC (original
> model). Since I had Debian "Wheezey" loaded on the APC, that's where I
> have done testing so far.
>
> Following the "Getting Started" guide on the web site was straight
> forward. All of the prerequisite packages were available and easily
> installed with apt or pip... neo4j was installed from its tar ball and
> run with the IcedTea v7 JVM.
>
> The Assimilation source code was checked out with mercurial and built as
> specified with no problems (including creating .deb packages).
>
> Below is a list of issues I have encountered so far:
>
> Issue 1: at present, there is a conflict with the
> /usr/share/assimilation/copyright file between the cma and nanoprobe deb
> packages, so one must be installed with the --force-overwrite flag
> passed to the dpkg command.
I think I fixed that (last night?). There are still debian-standards
issues with how I'm doing things - and how cpack allows me to do them,
but that complaint is more serious - so I made it go away.
>
> Issue 2: having IPv6 support in the kernel is mandatory. I had to
> rebuild mine and enable support. I'm not sure how common it is to have
> this disabled by default, but I suspect it's "not uncommon" on these
> small systems with limited resources.
Not planning on addressing this any time soon.
>
> Issue 3: the valgrind test fails miserably, but I believe this may be
> due to platform issues and not the assimilation code. I have pasted
> output at the end of this post (so it doesn't clutter this section).
> Note that the testify and pinger tests run successfully.
I see that. I don't see how my code could have caused these issues -
but sometimes I just discover that I don't see very well. This is
really unfortunate.
Did you try to start nanoprobe on a machine? How about the CMA? If
you did both, did you do any of the queries I suggest in the document?
>
> Issue 4: the Getting Started document states "These tests require that
> the CMA and nanoprobe are not stopped on the current machine while they
> run.", but the pinger test fails if they are running.
The not is an error. They MUST be stopped. Or "are not running".
I'm surprised they interfere with pinger... I'll check that out. But
the other tests definitely sit on the same port so they are in conflict.
>
> Issue 5: the cpu discovery agent only understands the format of
> /proc/cpuinfo on x86 hardware. The format for ARM is quite different. I
> looked at the format on both the APC and the RPi and it is at least
> consistent between these two. Hopefully it's consistent for all ARM
> based platforms.
>
> * Output from /proc/cpuinfo on the APC device:
>
> Processor : ARMv6-compatible processor rev 7 (v6l)
> BogoMIPS : 532.24
> Features : swp half thumb fastmult vfp edsp java
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x0
> CPU part : 0xb76
> CPU revision : 7
>
> Hardware : WMT
> Revision : 0000
> Serial : 0000000000000000
Thanks! That helps.
>
> * Output from grind.sh:
>
> ==21711== Invalid write of size 4
> ==21711== at 0x4B15314: __pthread_initialize_minimal (nptl-init.c:291)
> ==21711== by 0x4B13B1F: ??? (in
> /lib/arm-linux-gnueabihf/libpthread-2.13.so)
> ==21711== Address 0x4001ecfc is not stack'd, malloc'd or (recently) free'd
> ==21711==
> {
> <insert_a_suppression_name_here>
> Memcheck:Addr4
> fun:__pthread_initialize_minimal
> obj:/lib/arm-linux-gnueabihf/libpthread-2.13.so
> }
> ==21711==
> ==21711== Process terminating with default action of signal 11 (SIGSEGV)
> ==21711== Access not within mapped region at address 0x4001ECFC
> ==21711== at 0x4B15314: __pthread_initialize_minimal (nptl-init.c:291)
> ==21711== by 0x4B13B1F: ??? (in
> /lib/arm-linux-gnueabihf/libpthread-2.13.so)
> ==21711== If you believe this happened as a result of a stack
> ==21711== overflow in your program's main thread (unlikely but
> ==21711== possible), you can try to increase the size of the
> ==21711== main thread stack using the --main-stacksize= flag.
> ==21711== The main thread stack size used in this run was 8388608.
> ==21711== Invalid read of size 4
> ==21711== at 0x400E5EC: _dl_fixup (dl-runtime.c:109)
> ==21711== by 0x4014BFF: _dl_runtime_resolve (dl-trampoline.S:62)
> ==21711== by 0x48274F7: _vgnU_freeres (vg_preloaded.c:61)
> ==21711== by 0x4B152EB: __pthread_initialize_minimal (nptl-init.c:288)
> ==21711== by 0xFFFFFFFF: ???
> ==21711== Address 0x4001eb70 is not stack'd, malloc'd or (recently) free'd
> ==21711==
> {
> <insert_a_suppression_name_here>
> Memcheck:Addr4
> fun:_dl_fixup
> fun:_dl_runtime_resolve
> fun:_vgnU_freeres
> fun:__pthread_initialize_minimal
> obj:*
> }
> ==21711==
> ==21711== Process terminating with default action of signal 11 (SIGSEGV)
> ==21711== Access not within mapped region at address 0x4001EB70
> ==21711== at 0x400E5EC: _dl_fixup (dl-runtime.c:109)
> ==21711== by 0x4014BFF: _dl_runtime_resolve (dl-trampoline.S:62)
> ==21711== by 0x48274F7: _vgnU_freeres (vg_preloaded.c:61)
> ==21711== by 0x4B152EB: __pthread_initialize_minimal (nptl-init.c:288)
> ==21711== by 0xFFFFFFFF: ???
> ==21711== If you believe this happened as a result of a stack
> ==21711== overflow in your program's main thread (unlikely but
> ==21711== possible), you can try to increase the size of the
> ==21711== main thread stack using the --main-stacksize= flag.
> ==21711== The main thread stack size used in this run was 8388608.
> ~/assimilation/testcode/grind.sh: line 30: 21711 Segmentation fault
> valgrind -q --sim-hints=lax-ioctls --leak-check=full
> --show-reachable=yes --suppressions=$HERE/valgrind-msgs.supp $GEN
> --error-exitcode=100 --trace-children=no --child-silent-after-fork=yes
> ./mainlooptest $REPCOUNT
Did you try running mainlooptest outside of valgrind and/or under gdb?
Thanks for your report!
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
