On 04/04/2013 04:06 PM, Alan Robertson wrote:
> 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.
The issue is still present. I purged both packages and installed from
scratch:
$ sudo dpkg --install assimilation-cma-0.1.0-all.deb
assimilation-nanoprobe-0.1.0-armhf.deb
Selecting previously unselected package assimilation-cma-0.1.0-all.
(Reading database ... 109329 files and directories currently installed.)
Unpacking assimilation-cma-0.1.0-all (from
assimilation-cma-0.1.0-all.deb) ...
Selecting previously unselected package assimilation-nanoprobe-0.1.0-armhf.
Unpacking assimilation-nanoprobe-0.1.0-armhf (from
assimilation-nanoprobe-0.1.0-armhf.deb) ...
dpkg: error processing assimilation-nanoprobe-0.1.0-armhf.deb (--install):
trying to overwrite '/usr/share/assimilation/copyright', which is also
in package assimilation-cma-0.1.0-all 0.1.0
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Setting up assimilation-cma-0.1.0-all (0.1.0) ...
update-rc.d: using dependency based boot sequencing
update-rc.d: error: unable to read /etc/init.d/nanoprobe
dpkg: error processing assimilation-cma-0.1.0-all (--install):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
assimilation-nanoprobe-0.1.0-armhf.deb
assimilation-cma-0.1.0-all
>> 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?
Both CMA and nanoprobe start and run fine! I've run them in the
foreground, started manually on the command line, and let them start
automatically at boot time.
I ran through each of the queries in the document and they all returned
something... even if something was nothing... not much going on in an
environment with one nanoprobe :-) The point is that no queries failed
(although the time it took to execute some of them was a bit painful,
but nobody ever recommended running a CMA on this type of system!)
>> 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?
I ran mainlooptest outside of valgrind and it fails:
<snip>
** Message: Connected to CMA. Happiness :-D
** (process:23867): WARNING **: Peer at address 10.10.10.4:1984 is dead
(has timed out).
** Message: CMA Received dead host notification (type 26) over the 'wire'.
** Message: QUITTING NOW! (heartbeat count)
** (process:23867): WARNING **: _fsprotocol_send1.855: Attempt to send
FrameSet while link shutting down - FrameSet ignored.
** (process:23867): WARNING **: _fsproto_fsa.222: Got a 5 input for
[::1]:1984/0 while in state 0
** (process:23867): WARNING **: _fsproto_fsa.225: Frameset given was:
FrameSet(fstype=17, [[{SignFrame object at 0x0x1f658}],
[SeqnoFrame(type=4, (273051785,0,6))], [{Frame object at 0x0x1e848}]])
** Message: Count of 'other' pkts received: 1
GLib (gthread-posix.c): Unexpected error from C library during
'pthread_mutex_lock': Invalid argument. Aborting.
</snip>
I'm not sure where the 10.10.10.4 IP address comes from... it's not my
local network, but that failure seems to be the beginning of the end for
the test.
As for running within valgrind, I looked through some strace output and
it definitely never makes it to running mainlooptest. There seem to just
be fundamental issues on the ARM platform at this time (e.g., glibc,
pthreads, etc.). This is not an officially blessed Debian port and I
suspect little QA work has been done, especially running valgrind on a
system that has about 300MB of free memory to work with :-)
>
> Thanks for your report!
>
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
