SETI@home 7.25 for ARM Android released

Message boards : News : SETI@home 7.25 for ARM Android released
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · 5 · 6 . . . 14 · Next

AuthorMessage
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 49276 - Posted: 10 Feb 2014, 19:01:59 UTC - in response to Message 49269.  

And another observation:

when I tried to run app offline I got "SIGSEGV" errors until switched to superuser via su command.
Then Mateuzs' app started to work and stock started to fail on SIGILL. Before both failed on SIGSEGV.

So, something preventing app to run under user acc offline. Why ? Why superuser required (again, OFFLINE run from command line). File security was 777, that is, all for all.
Directory seсurity ? But why misleading SIGSEGV then not complains about file errors?

Maybe random SIGSEGVs reported by many somehow connected with this "superuser needed" issue ?


Only thing I can think of is that the app doesn't satisfy the OS requirements to stay alive.


But just su... same memory requirements, all the same, just superuser privileges granted.
ID: 49276 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 26,876,067
RAC: 1,317
United States
Message 49277 - Posted: 10 Feb 2014, 19:18:44 UTC - in response to Message 49269.  

... superuser mode ...


Which directory were you working in? By default the BOINC tree is owned by the boinc app user and is only readable by that user (and root). I wonder if an attempt to map the shared memory segment is failing.
ID: 49277 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 26,876,067
RAC: 1,317
United States
Message 49278 - Posted: 10 Feb 2014, 19:19:47 UTC

I'll be working on the NEON SIGILL today.
ID: 49278 · Report as offensive
Linux? You're kidding me!!
Volunteer tester
Avatar

Send message
Joined: 10 Mar 12
Posts: 1645
Credit: 12,157,307
RAC: 15,483
Sweden
Message 49281 - Posted: 10 Feb 2014, 21:45:00 UTC
Last modified: 10 Feb 2014, 21:47:38 UTC

And my second SETI@home v7 v7.25 (armv6-vfp) finished and validated without any problems at all:

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=16026956

V7.25 is slow, but it works perfectly for me. Am I really the only one it works for?

I must be doing something wrong :-)
WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.
ID: 49281 · Report as offensive
Profile Bernie Vine
Volunteer moderator
Volunteer tester

Send message
Joined: 11 Nov 12
Posts: 851
Credit: 2,974,438
RAC: 454
United Kingdom
Message 49282 - Posted: 11 Feb 2014, 9:21:17 UTC
Last modified: 11 Feb 2014, 9:24:37 UTC

Am I really the only one it works for?


Since V7.25 was released I have had 2 V7.24 tasks, both VLARS, the first has completed and validated the second finished early with -9 error and two other crunchers with V7.25 got "Error while computing"

I have finally got a V7.25 task this morning, it is also a VLAR and currently has been running for 5hrs 3m and completed 9.4%

PS my device is not a phone it is a TV streaming box so runs 24/7 on mains power (doesn't have batteries.)
ID: 49282 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 49286 - Posted: 11 Feb 2014, 9:38:49 UTC - in response to Message 49277.  

... superuser mode ...


Which directory were you working in? By default the BOINC tree is owned by the boinc app user and is only readable by that user (and root). I wonder if an attempt to map the shared memory segment is failing.


I did offline testing in completely separate directory.
It was /data/seti
ID: 49286 · Report as offensive
Profile Raistmer
Volunteer tester
Avatar

Send message
Joined: 18 Aug 05
Posts: 2423
Credit: 15,878,738
RAC: 0
Russia
Message 49287 - Posted: 11 Feb 2014, 9:42:13 UTC - in response to Message 49281.  


V7.25 is slow, but it works perfectly for me. Am I really the only one it works for?

I must be doing something wrong :-)


Perhaps you should just take into account big variability of ARM CPU models under Android.
ID: 49287 · Report as offensive
Virtual Boss*
Volunteer tester

Send message
Joined: 10 Feb 14
Posts: 3
Credit: 10,125
RAC: 0
Australia
Message 49289 - Posted: 11 Feb 2014, 12:56:13 UTC - in response to Message 49270.  

Newbie question:

I have just crested an account and attached an android device.

I noticed 2 apps on the applications page:

Android (ARM processor)7.24 (armv7-vfpv4)5 Dec 2013, 1:50:57 UTC
Android (ARM processor)7.25 (armv6-vfp)6 Feb 2014, 22:32:07 UTC

The application I got automatically from tge server is the 7.25 armv6.

My processor is an ARMv7 Processor rev 10 (v7l) @996MHz(4 processors).

Was I given the correct app?

EDIT: First task errored @ ~2 minutes wall time.
Have set NNT for now.


I am assuming I have the correct app.

Task #1
Stderr output
<core_client_version>7.0.36</core_client_version>
<![CDATA[
<message>
process got signal 11
</message>
<stderr_txt>
setiathome_v7 7.24 Revision: 2072 arm-linux-androideabi-g++ (GCC) 4.6 20120106 (prerelease)
libboinc: BOINC 7.3.0

Work Unit Info:
...............
WU true angle range is : 1.177297
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
vfp_GetPowerSpectrum 0.002904 0.00000
neon_ChirpData 0.049773 0.00000
v_pfTranspose4 0.029824 0.00000
opt NEON folding 0.004979 0.00000
SIGSEGV: segmentation violation
Manual call stack printout

</stderr_txt>
]]>


I have started another task, 2+ hrs later I realised it was still running but showing 0% complete, using 0% cpu and had not checkpointed.

I stopped the task, shut down boinc client, restarted boinc and restarted the task which started again at 0:00:00 time

About 3 minutes later cpu usage dropped to 0 but all else seemed to be running.

I let it run for another 2 hours with same outcome as first attempt.

During this 2 other cores were running POGS tasks and the last core was idle.
ID: 49289 · Report as offensive
Profile David S
Volunteer tester
Avatar

Send message
Joined: 10 Sep 13
Posts: 1187
Credit: 2,563,951
RAC: 1,593
United States
Message 49293 - Posted: 11 Feb 2014, 14:37:47 UTC
Last modified: 11 Feb 2014, 14:38:21 UTC

My phone did another v.25 yesterday and 4 more early this morning. All errors.

I looked at the stderr of each errored host on each of these WUs. I don't know if it's significant, but most if not all of the WUs had a mix of errors: a couple of code 193 - SIGILLs and a couple of SIGNAL 11 - SIGSEGVs. Every error is one of those combinations, except one that didn't say either SIGILL or SIGSEGV and one that decided to be different and say code 193 - SIGSEGV.

No Android device has completed any of these successfully. Most are out to regular computers now.
David
signature sent back to alpha testing
ID: 49293 · Report as offensive
Josef W. Segur
Volunteer tester

Send message
Joined: 14 Oct 05
Posts: 1137
Credit: 1,848,733
RAC: 0
United States
Message 49298 - Posted: 12 Feb 2014, 0:21:52 UTC - in response to Message 49265.  

Thanks for corrections I tend to forget more general approach of stock build to code path selection.
Well, then one could say that code path selection mechanism is broken in 7.25.
cpuinfo doesn't mention neon on that host. On what "cpuid" stock build based then ?

From analyzeFuncs_vector.cpp in the repository:

----------------------------------------------------------------
#elif defined(__arm__) && defined(__VFP_FP__) && !defined(__SOFTFP__)

#if defined(HAVE_CPU_FEATURES_H) && defined(ANDROID)
  uint64_t features=android_getCpuFeatures();
  if (features & ANDROID_CPU_ARM_FEATURE_ARMv7) CPUCaps |= BA_VFP;
  if (features & ANDROID_CPU_ARM_FEATURE_NEON)  CPUCaps |= BA_NEON;
#else
  CPUCaps |= BA_VFP;
  CPUCaps |= BA_NEON;
#endif
----------------------------------------------------------------


The https://code.google.com/p/android/issues/detail?id=43055 issue might be involved, in any case that thread gives some insight into how the android_getCpuFeatures() function should work.
                                                                  Joe
ID: 49298 · Report as offensive
arkayn
Volunteer tester
Avatar

Send message
Joined: 16 Jan 07
Posts: 155
Credit: 194,400
RAC: 0
United States
Message 49301 - Posted: 12 Feb 2014, 2:42:18 UTC

So far, 7.25 has actually been faster on my HTC One-V that 7.24, I still get the Segmentation error at the end, but it does not affect the work and it validates.
ID: 49301 · Report as offensive
Profile David S
Volunteer tester
Avatar

Send message
Joined: 10 Sep 13
Posts: 1187
Credit: 2,563,951
RAC: 1,593
United States
Message 49305 - Posted: 12 Feb 2014, 14:29:28 UTC

I don't suppose it's significant, but all the v7.25 STDERRs I've looked at are saying v7.24.

Every WU my phone has done as a v7.25 has not only returned an error from me, but also from every other Android that has worked on it. Makes me wonder what's going right for Sten and Arkayn.
David
signature sent back to alpha testing
ID: 49305 · Report as offensive
Profile David S
Volunteer tester
Avatar

Send message
Joined: 10 Sep 13
Posts: 1187
Credit: 2,563,951
RAC: 1,593
United States
Message 49306 - Posted: 12 Feb 2014, 14:41:20 UTC - in response to Message 49301.  

I still get the Segmentation error at the end, but it does not affect the work and it validates.

I see Sten did NOT get the SIGSEGV on the two he has finished so far. Odd.

I also see that other Androids did get errors on the WUs you guys didn't.
David
signature sent back to alpha testing
ID: 49306 · Report as offensive
jason_gee
Volunteer tester

Send message
Joined: 11 Dec 08
Posts: 198
Credit: 658,573
RAC: 0
Australia
Message 49309 - Posted: 12 Feb 2014, 14:58:10 UTC - in response to Message 49305.  
Last modified: 12 Feb 2014, 15:44:59 UTC

I don't suppose it's significant, but all the v7.25 STDERRs I've looked at are saying v7.24.

Every WU my phone has done as a v7.25 has not only returned an error from me, but also from every other Android that has worked on it. Makes me wonder what's going right for Sten and Arkayn.


With the huge variety of ARM devices, there's a strong probability different implementations are sensitive more or less than others to certain design issues.

One good example is the segmentation violation, that appears benign on Arkayn's while usually catastrophic on my Google Nexus 7 (2013). That's actually a symptom pointing straight at BoincApi, simply because it occurs usually after Boinc Finish is called (purely under boincapi control by that stage). That of course isn't the only issue, SIGGILLS for example are more likely one of code and feature detection, but one example of a symptom of something deeper going on.

The reasons for such variability In that particular (segmentation violation) case, when you look deeper, appear to lie in a mismatch between the threading model assumed by the Boinc client, Boincapi and that prescribed by Android and its libraries. That's the same set of 'programming model' mismatches that cause totally different symptoms elsewhere, like truncated Stderr on Windows hosts, and 'sticky downclocks' on Cuda applications using unmodified boincapi.

So the symptoms will vary, but likely originate from some relatively narrow set of core design issues that need resolving.

That's possibly amplified with Android, because C runtime libraries are likely to be steadily adopting usability optimisations involving multithreading, more or less mirroring the process Windows did from 2003 onwards. Other Linux distros and libraries appear to also be beginning to follow suit, optimising heavily for low power mobile devices, while maintaining quick user response.

That tends to make use of more features like IO completion, and deferred procedure calls, which are fundamentally incompatible with some of the dated non-threadsafe assumptions Boinc makes during process management.
ID: 49309 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 26,876,067
RAC: 1,317
United States
Message 49310 - Posted: 12 Feb 2014, 16:27:58 UTC - in response to Message 49298.  


From analyzeFuncs_vector.cpp in the repository:

----------------------------------------------------------------
#elif defined(__arm__) && defined(__VFP_FP__) && !defined(__SOFTFP__)

#if defined(HAVE_CPU_FEATURES_H) && defined(ANDROID)
  uint64_t features=android_getCpuFeatures();
  if (features & ANDROID_CPU_ARM_FEATURE_ARMv7) CPUCaps |= BA_VFP;
  if (features & ANDROID_CPU_ARM_FEATURE_NEON)  CPUCaps |= BA_NEON;
#else
  CPUCaps |= BA_VFP;
  CPUCaps |= BA_NEON;
#endif
----------------------------------------------------------------


The https://code.google.com/p/android/issues/detail?id=43055 issue might be involved, in any case that thread gives some insight into how the android_getCpuFeatures() function should work. [pre]


The 7.25 version distributed skips android_getCpuFeatures() and goes direct to /proc/cpuinfo (which is where android_getCpuFeatures gets its info from anyway). But there's still a bug somewhere that allows non-neon processors to think they can use NEON apps.
ID: 49310 · Report as offensive
Profile David S
Volunteer tester
Avatar

Send message
Joined: 10 Sep 13
Posts: 1187
Credit: 2,563,951
RAC: 1,593
United States
Message 49311 - Posted: 12 Feb 2014, 19:11:54 UTC - in response to Message 49310.  

The 7.25 version distributed skips android_getCpuFeatures() and goes direct to /proc/cpuinfo (which is where android_getCpuFeatures gets its info from anyway). But there's still a bug somewhere that allows non-neon processors to think they can use NEON apps.

Hmm.

After (I want to emphasize after) my phone had all those errors, I signed it up with Einstein. Every task it does there says it's NEON. Don't know if that's relevant, but I thought I'd mention it.
David
signature sent back to alpha testing
ID: 49311 · Report as offensive
zombie67 [MM]
Volunteer tester
Avatar

Send message
Joined: 18 May 06
Posts: 280
Credit: 26,291,279
RAC: 1,136
United States
Message 49312 - Posted: 13 Feb 2014, 0:09:30 UTC
Last modified: 13 Feb 2014, 1:03:37 UTC

My GS3 has crunched 27 tasks, all without error:

http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=69068

This includes the following apps:

SETI@home v7 v7.24 (armv6-vfp)
SETI@home v7 v7.24 (armv7-vfpv4)
SETI@home v7 v7.23 (armv6-vfp)
SETI@home v7 v7.23 (armv7-vfpv4)

I haven't received any v7.25 yet.

Is there any help I can offer, other than just continuing to crunch?
Dublin, California
Team: SETI.USA

ID: 49312 · Report as offensive
Profile Eric J Korpela
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 15 Mar 05
Posts: 1547
Credit: 26,876,067
RAC: 1,317
United States
Message 49313 - Posted: 13 Feb 2014, 0:57:28 UTC - in response to Message 49312.  

It's nice to hear it works for someone. ;) Just keep crunching. I anticipate 7.26 will be out shortly, but since you are crunching fine and fast with the VFPv4 version, you might not get it.
ID: 49313 · Report as offensive
Claggy
Volunteer tester

Send message
Joined: 29 May 06
Posts: 1037
Credit: 8,439,427
RAC: 0
United Kingdom
Message 49316 - Posted: 13 Feb 2014, 2:34:23 UTC - in response to Message 49313.  
Last modified: 13 Feb 2014, 2:37:06 UTC

It's nice to hear it works for someone. ;) Just keep crunching. I anticipate 7.26 will be out shortly, but since you are crunching fine and fast with the VFPv4 version, you might not get it.

It works and validates on my old single core HTC Desire running Android 2.2 and NativeBoinc too, But it gives these:

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=16030488
<core_client_version>7.0.36</core_client_version>
<![CDATA[
<stderr_txt>
Unable to resolve function unwind_backtrace_signal_arch
Unable to resolve function acquire_my_map_info_list
Unable to resolve function release_my_map_info_list
Unable to resolve function get_backtrace_symbols
Unable to resolve function free_backtrace_symbols
Unable to resolve function format_backtrace_line
Unable to resolve function load_symbol_table
Unable to resolve function free_symbol_table
Unable to resolve function find_symbol
one or more symbols not found. stackdumps unavailable

setiathome_v7 7.24 Revision: 2072 arm-linux-androideabi-g++ (GCC) 4.6 20120106 (prerelease)
libboinc: BOINC 7.3.0

Work Unit Info:
...............
WU true angle range is : 4.267065
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
vfp_GetPowerSpectrum (CPU Caps)
neon_ChirpData (CPU Caps)
v_Transpose4 (default)
neonFoldMain (CPU Caps)

Flopcounter: 16053873871380.144531

Spike count: 0
Autocorr count: 0
Pulse count: 0
Triplet count: 3
Gaussian count: 0
16:26:46 (14301): called boinc_finish
SIGSEGV: segmentation violation
Manual call stack printout
2 x&#247;6
1 @&#233;&#255;&#255;Q


Exiting...


Claggy
ID: 49316 · Report as offensive
arkayn
Volunteer tester
Avatar

Send message
Joined: 16 Jan 07
Posts: 155
Credit: 194,400
RAC: 0
United States
Message 49317 - Posted: 13 Feb 2014, 2:41:01 UTC - in response to Message 49316.  

It's nice to hear it works for someone. ;) Just keep crunching. I anticipate 7.26 will be out shortly, but since you are crunching fine and fast with the VFPv4 version, you might not get it.

It works and validates on my old single core HTC Desire running Android 2.2 and NativeBoinc too, But it gives these:

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=16030488
<core_client_version>7.0.36</core_client_version>
<![CDATA[
<stderr_txt>
Unable to resolve function unwind_backtrace_signal_arch
Unable to resolve function acquire_my_map_info_list
Unable to resolve function release_my_map_info_list
Unable to resolve function get_backtrace_symbols
Unable to resolve function free_backtrace_symbols
Unable to resolve function format_backtrace_line
Unable to resolve function load_symbol_table
Unable to resolve function free_symbol_table
Unable to resolve function find_symbol
one or more symbols not found. stackdumps unavailable

setiathome_v7 7.24 Revision: 2072 arm-linux-androideabi-g++ (GCC) 4.6 20120106 (prerelease)
libboinc: BOINC 7.3.0

Work Unit Info:
...............
WU true angle range is : 4.267065
Optimal function choices:
--------------------------------------------------------
name timing error
--------------------------------------------------------
v_BaseLineSmooth (no other)
vfp_GetPowerSpectrum (CPU Caps)
neon_ChirpData (CPU Caps)
v_Transpose4 (default)
neonFoldMain (CPU Caps)

Flopcounter: 16053873871380.144531

Spike count: 0
Autocorr count: 0
Pulse count: 0
Triplet count: 3
Gaussian count: 0
16:26:46 (14301): called boinc_finish
SIGSEGV: segmentation violation
Manual call stack printout
2 x&#247;6
1 @&#233;&#255;&#255;Q


Exiting...


Claggy


That is the same thing that mine is doing as well.
ID: 49317 · Report as offensive
Previous · 1 · 2 · 3 · 4 · 5 · 6 . . . 14 · Next

Message boards : News : SETI@home 7.25 for ARM Android released


 
©2019 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.