SETI@Home Enhanced on Raspberry Pi using Archlinux
HOME PARTICIPATE ABOUT COMMUNITY ACCOUNT STATISTICS
log in

Advanced search

Questions and Answers : Unix/Linux : SETI@Home Enhanced on Raspberry Pi using Archlinux

Subscribe Sort
Author Message
dcarrion87
Send message
Joined: 14 Oct 12
Posts: 6
Credit: 19,886
RAC: 0
Australia
Message 1306716 - Posted: 16 Nov 2012, 8:35:15 UTC

Hey Guys

So I managed to get client version 5.13 from the Debian boinc-app-seti working on my Raspberry Pi Archlinux setup. Application details:

application: setiathome_enhanced
version: 5.13
project: SETI@home

I want to ask is if there is a different version that would be optimal. I tried compiling the latest and pointing to various app versions in my app_info.xml file for SETI but I keep getting the following errors:

[SETI@home] This project doesn't support computers of type armv6l-unknown-linux-gnueabihf

If I use latest client and point app_info.xml to app version 5.13 I just keep getting exit errors as soon as the task starts (assuming because the task isn't compatible).

Is there an easy way to find out what app versions are supported for ARM and which I should be using? I know it's not the most heavily supported platform for fpops but I plan on loading this setup on a bucketload of Raspberry Pis.

I could just keep using 5.13 with older client, I guess...Hope to hear back from someone soon.

Cheers

Daniel

ID: 1306716 · Report as offensive
dcarrion87
Send message
Joined: 14 Oct 12
Posts: 6
Credit: 19,886
RAC: 0
Australia
Message 1308297 - Posted: 21 Nov 2012, 10:22:49 UTC - in response to Message 1306716.
Last modified: 21 Nov 2012, 11:20:35 UTC

Well I was mistaken and the 5.13 app is producing invalid results.

I've managed to get a compiled version of 7.0 and running in standalone mode on a work unit. However, as soon as I run with BOINC I'm seeing instant completion of jobs with this in the client_state.xml file:

<result>
<name>31au12aa.15618.19462.140733193388038.10.205_3</name>
<final_cpu_time>0.000000</final_cpu_time>
<final_elapsed_time>0.000000</final_elapsed_time>
<exit_status>11</exit_status>
<state>3</state>
<platform>armv6l-unknown-linux-gnueabihf</platform>
<version_num>610</version_num>
<stderr_out>
<![CDATA[
<message>
process got signal 11
</message>
<stderr_txt>

</stderr_txt>
]]>


I managed to run it manually in the slot with GDB. Error:

Starting program: /var/lib/boinc/projects/setiathome.berkeley.edu/setiathome_enhanced
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x401c2c80 in _armv7_neon_probe () from /usr/lib/libcrypto.so.1.0.0


Had a bit of a look around at libcrypto and saw that there's a crypto assembler file armv4cpuid.S that does a neon probe:

#include "arm_arch.h"

.text
.code 32

.align 5
.global _armv7_neon_probe
.type _armv7_neon_probe,%function
_armv7_neon_probe:
.word 0xf26ee1fe @ vorr q15,q15,q15
.word 0xe12fff1e @ bx lr



I'm guessing this is getting called for some reason even though the Raspberry Pi ARMv6 processor does not have NEON logical and compare support.

Continuing investigation...

ID: 1308297 · Report as offensive
dcarrion87
Send message
Joined: 14 Oct 12
Posts: 6
Credit: 19,886
RAC: 0
Australia
Message 1308322 - Posted: 21 Nov 2012, 12:20:12 UTC - in response to Message 1308297.

OK, I managed to get around that NEON instruction problem by doing:

export OPENSSL_armcap=6


Looks like this bit of code in armcap.c in crypto library allowed me to bypass:

if ((e=getenv("OPENSSL_armcap")))
{
OPENSSL_armcap_P=strtoul(e,NULL,0);
return;
}


Running again we get more issues:

(gdb) run
Starting program: /var/lib/boinc/projects/setiathome.berkeley.edu/setiathome_enhanced
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x4002b460 (LWP 226)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4002b460 (LWP 226)]
0x4000eaf4 in _dl_fixup () from /lib/ld-linux.so.3
(gdb) bt
#0 0x4000eaf4 in _dl_fixup () from /lib/ld-linux.so.3
#1 0x40015534 in _dl_runtime_resolve () from /lib/ld-linux.so.3
#2 0x40032bf4 in handle_heartbeat_msg () at boinc_api.cpp:363
#3 0x400350c8 in timer_handler () at boinc_api.cpp:1126
#4 timer_thread () at boinc_api.cpp:1239
#5 0x40453d60 in start_thread () from /usr/lib/libpthread.so.0
#6 0x40537d48 in ?? () from /usr/lib/libc.so.6
Cannot access memory at address 0x0
#7 0x40537d48 in ?? () from /usr/lib/libc.so.6
Cannot access memory at address 0x0


Eeerrr yuk...

That's enough for me tonight I think. Might tackle again in a day or so if I have time.

ID: 1308322 · Report as offensive
dcarrion87
Send message
Joined: 14 Oct 12
Posts: 6
Credit: 19,886
RAC: 0
Australia
Message 1308363 - Posted: 21 Nov 2012, 14:49:31 UTC - in response to Message 1308322.

So I thought I'd kick off a compile of the latest versions of BOINC and seti_boinc and come back a bit later.

Versions:

BOINC 7.1.0 (Revision 26154)
SETI 7.0 (Revision 1717)

I also noticed that pacman had a new version of OpenSSL for me.

Compilation went well. Set to run manually and attempted manual invocation from slot 0 - ../../projects/setiathome.berkeley.edu/setiathome_enhanced.

Looks like SETI started to crunch this time without any errors. However, after some time it exited (normally) and had a delightful error message for me waiting in stderr.txt:

14:37:09 (23461): No heartbeat from client for 30 sec - exiting


I think I will stick with these versions and see if I can work out this heartbeat issue...

Any active developers out there that can provide any guidance?

ID: 1308363 · Report as offensive
Profile arkayn
Volunteer tester
Avatar
Send message
Joined: 14 May 99
Posts: 3086
Credit: 40,254,388
RAC: 65,765
United States
Message 1308377 - Posted: 21 Nov 2012, 15:38:35 UTC - in response to Message 1308363.

Not a developer, but this might make testing the apps a little bit easier.
http://www.arkayn.us/forum/index.php?topic=11.0
____________

ID: 1308377 · Report as offensive
WezH
Volunteer tester
Send message
Joined: 19 Aug 99
Posts: 67
Credit: 2,173,302
RAC: 4,192
Finland
Message 1308379 - Posted: 21 Nov 2012, 15:45:18 UTC - in response to Message 1308363.

Any active developers out there that can provide any guidance?


Maybe You should register in Seti@Home Beta and share Your ideas/troubles in Beta forums.
____________

ID: 1308379 · Report as offensive
Eric Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar
Send message
Joined: 3 Apr 99
Posts: 952
Credit: 5,665,006
RAC: 5,864
United States
Message 1308470 - Posted: 21 Nov 2012, 19:49:55 UTC - in response to Message 1308297.
Last modified: 21 Nov 2012, 19:50:17 UTC



I managed to run it manually in the slot with GDB. Error:

Starting program: /var/lib/boinc/projects/setiathome.berkeley.edu/setiathome_enhanced
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x401c2c80 in _armv7_neon_probe () from /usr/lib/libcrypto.so.1.0.0



One thing to watch for when using GDB is that signals will be caught by GDB even if there is a signal handler in place. It's common practice to install a signal handler for SIGILL and the execute an instruction to see if it is supported. FFTW uses this method and SETI@home uses this method.

Outside of GDB the signal will be caught if it is raised and then the routines that use the illegal instruction will be avoided. Inside GDB the signal will be caught by GDB by default. If you just continue from this point, it may work. The other option is to tell GDB not to catch SIGILL.
____________

ID: 1308470 · Report as offensive
Eric Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar
Send message
Joined: 3 Apr 99
Posts: 952
Credit: 5,665,006
RAC: 5,864
United States
Message 1308479 - Posted: 21 Nov 2012, 19:56:30 UTC - in response to Message 1308363.


14:37:09 (23461): No heartbeat from client for 30 sec - exiting


I think I will stick with these versions and see if I can work out this heartbeat issue...

Any active developers out there that can provide any guidance?


That might mean that the client is getting stuck in the section that benchmarks the science routines. The default choice of timer might not be working for you. If ARM supports a cycle counter you can add the code to client/vector/hires_timer.{cpp,h}
____________

ID: 1308479 · Report as offensive
dcarrion87
Send message
Joined: 14 Oct 12
Posts: 6
Credit: 19,886
RAC: 0
Australia
Message 1308616 - Posted: 22 Nov 2012, 4:36:17 UTC - in response to Message 1308479.

Thanks for the responses!

That might mean that the client is getting stuck in the section that benchmarks the science routines. The default choice of timer might not be working for you. If ARM supports a cycle counter you can add the code to client/vector/hires_timer.{cpp,h}


Well it restarts after 10 seconds on both ARM and x86 machine (compiled same versions). The x86 machine seems to get a little further (past benchmarking it seems) but still bombs out with "No heartbeat from client for 30 sec - exiting".

I'll check out the forum arkayn linked me once my registration has been approved.


ID: 1308616 · Report as offensive
Profile arkayn
Volunteer tester
Avatar
Send message
Joined: 14 May 99
Posts: 3086
Credit: 40,254,388
RAC: 65,765
United States
Message 1308648 - Posted: 22 Nov 2012, 6:47:00 UTC - in response to Message 1308616.

Thanks for the responses!

That might mean that the client is getting stuck in the section that benchmarks the science routines. The default choice of timer might not be working for you. If ARM supports a cycle counter you can add the code to client/vector/hires_timer.{cpp,h}


Well it restarts after 10 seconds on both ARM and x86 machine (compiled same versions). The x86 machine seems to get a little further (past benchmarking it seems) but still bombs out with "No heartbeat from client for 30 sec - exiting".

I'll check out the forum arkayn linked me once my registration has been approved.




Already done.
____________

ID: 1308648 · Report as offensive
dcarrion87
Send message
Joined: 14 Oct 12
Posts: 6
Credit: 19,886
RAC: 0
Australia
Message 1309113 - Posted: 23 Nov 2012, 5:47:01 UTC - in response to Message 1308648.
Last modified: 23 Nov 2012, 5:58:38 UTC

Just thought I'd update to say I've had some success. During my recent testing I ended up reverting back to Raspbian (instead of ArchLinux) as there was significant improvement in performance.

I ended up compiling and getting these versions working together:

BOINC 6.12.34
SETI 6.12

The Raspberry Pi has now downloaded and crunching a work unit. Now I just have to wait for it to finish processing. Hopefully no computation errors! Seems to be returning valid results when compiled on x86 Ubuntu: http://setiathome.berkeley.edu/result.php?resultid=2723661285

Thanks to Jose Da Silva who responded on the boinc_opt mailing list, giving me hints about trying versions 6.X of BOINC.

I will continue to try and get versions 7.X of BOINC working with SETI.

I have posted a little Raspberry Pi BOINC instructional at http://burdeview.blogspot.com.au if anyone is interested.

Thanks again for your responses.

ID: 1309113 · Report as offensive

Questions and Answers : Unix/Linux : SETI@Home Enhanced on Raspberry Pi using Archlinux

HOME PARTICIPATE ABOUT COMMUNITY ACCOUNT STATISTICS
Copyright © 2013 University of California