I'm running ateroids@home on a Raspberry Pi 1B+ and currently have 165 work units that have returned an "error while computing." The Task detail shows:

Stderr output

<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
process got signal 4</message>
<stderr_txt>

</stderr_txt>
]]>

This computer was processing work units satisfactorily until today. How to correct the problem?

Just noticed that a new version of the asteroids application is used by my Raspberry Pi: it's now 102.13; formerly it was 102.1. Could that be the cause of the problem?

I'm running ateroids@home on a Raspberry Pi 1B+ and currently have 165 work units that have returned an "error while computing." The Task detail shows:

Stderr output

<core_client_version>7.14.2</core_client_version>
<![CDATA[
<message>
process got signal 4</message>
<stderr_txt>

</stderr_txt>
]]>

This computer was processing work units satisfactorily until today. How to correct the problem?

The Boinc error codes say this means:
https://boinc.mundayweb.com/wiki/index.php?title=Process_got_signal_4

"This process error can happen when your BOINC version is outdated. Try to update to a more up-to-date version. The problem can also be attributed to a large amount of disk errors."

In your case the Boinc version is up to date, there is a newer one but maybe not for the Pi.

Thank you, Mikey, for your reply.

With no intervention on my part, the Pi 1B+ is now processing a work unit. This is after 295 work units were downloaded today and failed with "error while computing."

Hopefully, the problem is solved, albeit mysteriously.

Thank you, Mikey, for your reply.

With no intervention on my part, the Pi 1B+ is now processing a work unit. This is after 295 work units were downloaded today and failed with "error while computing."

Hopefully, the problem is solved, albeit mysteriously.

I would make a backup disk for your Pi just in case they come back, shut things down swap disks and start back up again and see if it works, if so it's a disk problem.

They updated their ARM application a couple of days ago (version 102.13) and it now needs GLIBC 2.28 to run, which I don't have since I use Raspbian Stretch lite. So my Raspberry pi Zero now has problems because of that. Every task errors out within a second.

Who knows what else they may have changed in this new version of the application.

I too noticed that updated version 102.13 application and wondered if it would create problems. As mentioned above, the Pi 1B+ with the new application seems to be processing a work unit after many downloads with errors.

I also have two Raspberry Pi Zeros running asteroids@home. One finished a work unit this morning and is now failing to start another work unit successfully. It reports the same computation error that appeared for the B+ (see initial post). This Zero now has the new 102.13 app as well. At present, there are 57 work units for that Pi with errors.

All of the Pis have the latest Raspbian operating system (Buster) installed and updated. Glibc doesn't appear to be an installed package with Buster, but I may not be looking in the right place.

Any idea how we can get the Zeros to crunch ateroids@home with these new changes? It remains to be seen if the Pi 1B+ will finish its current work unit satisfactorily and *then* get new work without errors.

I'm getting the same errors on every thing that is running stretch (zero and 3b+) Raspberry 4 that run buster are processing just fine.

They updated their ARM application a couple of days ago (version 102.13) and it now needs GLIBC 2.28 to run, which I don't have since I use Raspbian Stretch lite.

Is there some reason why you aren’t upgrading to buster-lite?

The Glibc comes with the operating system, so upgrading it and probably BOINC should get you going again.

---

BOINC blog

Upgrading to Buster didn't get me going, the GLIBC error is now replaced with this error instead: process got signal 4

It appears as if the armv6l app isn't compatible with Raspberry pi 1B+ & Raspberry pi Zero anymore. So no more crunching on such devices I guess, at least for now.

So there are at least 2 things going on here:

1) You need to upgrade from Stretch to Buster. This should fix the GLIBC-error with any Raspberry pi.

2) The armv6l app used by Raspberry pi 1B+/Zero doesn't work anymore for unknown reasons.

Upgrading to Buster didn't get me going, the GLIBC error is now replaced with this error instead: process got signal 4

It appears as if the armv6l app isn't compatible with Raspberry pi 1B+ & Raspberry pi Zero anymore. So no more crunching on such devices I guess, at least for now.

So there are at least 2 things going on here:

1) You need to upgrade from Stretch to Buster. This should fix the GLIBC-error with any Raspberry pi.

2) The armv6l app used by Raspberry pi 1B+/Zero doesn't work anymore for unknown reasons.

I can’t test point 2, but are you sure you upgraded to buster? The kernel should be 4.19.97 and the version of BOINC should be 7.14.2. Yours appear to be older.

I tried a Pi4 on here after the app upgrade and the tasks took 35 hours so I don’t think they are using neon which the Pi2 and later have. I hate to think how long a 1st generation Pi would take.

---

BOINC blog

Just to followup on my last post in this thread, the Pi 1B+ with the 102.13 app finished the work unit sucessfully after about 11 days of crunching. For the duration of that period, the Pi was overclocked to 1000MHz.

Why does 102.13 app work with the 1B+ but not with the Pi Zeros? Both are ARMv6. However, at the moment, there doesn't seem to be any work available.

My raspberry 3B+ and Zeros that running stretch are getting constant computation errors. The raspberry 4's that are running buster are processing units properly. They have the latest boinc app installed. Please advise

My raspberry 3B+ and Zeros that running stretch are getting constant computation errors. The raspberry 4's that are running buster are processing units properly. They have the latest boinc app installed. Please advise

Did you try installing the latest app on the 3B+ and Zeros? Did you try installing Buster on the older Pi's? The older Pi's could have been pushed out due to the Project moving forward instead of standing still.

Both the zeros have buster and have the computation errors. One of my 3B+ has buster and is processing data. I guess i will have to convert the other 3B+ to buster (6 units) :-(

I expect the project has compiled the app using the current compiler. It doesn’t look like they’ve used the -march=armv7-a compile option either because tasks take so long on the Pi4.

As for the ARMv6 failing that suggests an app problem, probably an incorrect compile option again. We would need Kyong to recompile them.

---

BOINC blog

Both the zeros have buster and have the computation errors. One of my 3B+ has buster and is processing data. I guess i will have to convert the other 3B+ to buster (6 units) :-(

I have converted some of the 3B+ (1 hour labor for each one) to the Buster os and they seem to be working now. Although units have a predicted completion of 2 days.

I have converted some of the 3B+ (1 hour labor for each one) to the Buster os and they seem to be working now. Although units have a predicted completion of 2 days.

It might be right. My Pi4’s came in at 35 hours and they’re faster.

Usually with OS upgrades I find it easier to reimage the SD card from the iso file you download of Raspbian lite.and then reinstall BOINC on them. I have the config stuff on an NFS server which is just a Pi with an external hard drive.

---

BOINC blog

In case Kyong reads this, here are the CPU features of the different Raspberry Pi's that I have at hand. I don't have a Pi Zero but expect they would be the same as a Pi B+. I think -march=armv7-a should cover everything from a Pi2 upwards.

Pi model B+ (ARMv6)
half thumb fastmult vfp edsp java tls

Pi2 model B (ARMv7)
half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

Pi3 model B & Pi3 model B+ (ARMv7)
half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

Pi4 model B (ARMv8 armhf mode)
half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

Pi4 model B (ARMv8 aarch64 mode)
fp asimd evtstrm crc32 cpuid

---

BOINC blog

As a followup to MarkJ's post above, here is info from a Pi Zero (armv6l):

half thumb fastmult vfp edsp java tls