Actually, I don't use grub here, having failed to get it to boot on this UEFI machine. I use systemd-boot and efibootmgr instead. And, this being Gentoo, I have to compile my own kernels, which is why I quoted the kernel help text. I don't see anything there about passing a boot-time kernel parameter as well.
Yes, the new default is "vsyscall=none" which breaks old applications and you need to activate emulation again in order to get the apps working. The EaH apps fail right at the start so if you get it working but still see the messages they can be ignored.
There is now a GW ("O1Spot1") application version that has been compiled on Ubuntu 10.04 with LIBC 2.15 and thus should fix this problem without enabling vsyscalls. As there is currently no BOINC Client that detects and reports the LIBC version, there is no way to automatically choose which app version to deliver to the clients. Instead there is a new project-specific setting "Run Linux app versions built with LIBC 2.15" that you have to enable manually. Please give it a try and see if it works.
While testing there is only an app version for the GW search, so you probably want to disable other applications (FGRP*) to prevent these from failing.
There is now a GW ("O1Spot1") application version that has been compiled on Ubuntu 10.04 with LIBC 2.15 and thus should fix this problem without enabling vsyscalls.
Did you really mean 10.04? That’s positively ancient (circa 2012) wouldn’t a more recent one be better?
There is now a GW ("O1Spot1") application version that has been compiled on Ubuntu 10.04 with LIBC 2.15 and thus should fix this problem without enabling vsyscalls.
Hello
Can you help me in configuring project to use LIBC215 version?
I have checked "Run Linux app versions built with LIBC 2.15" option in project settings. I also disabled all applications except "Continuous Gravitational Wave search Galactic Center lowFreq" and "Continuous Gravitational Wave search Galactic Center highFreq" as you sugest. Still all calculations try to run on AVX version and crash with segmentation fault.
When I look in project directory BOINC Client downloads only einstein_O1Spot1Lo_1.00_x86_64-pc-linux-gnu__AVX executable. There is no any other vesion like LIBC215.
Should I set any other option somewhere?
I run calculations on Linux Debian Testing, so kernel and other packages are quite new:
CPU type: GenuineIntel Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz [Family 6 Model 23 Stepping 10]
Number of processors: 4
Coprocessors: ---
Operating system: Linux Debian Debian GNU/Linux testing (buster) [4.13.0-1-amd64]
BOINC client version: 7.8.3
And here copy of my project settings:
Applications
generic
home
school
work
Binary Radio Pulsar Search (Arecibo)
---
---
---
---
Binary Radio Pulsar Search (Arecibo, GPU)
---
---
---
---
Gamma-ray pulsar binary search #1
---
---
---
---
Gamma-ray pulsar search #5
---
---
---
---
Gamma-ray pulsar binary search #1 (GPU)
---
---
---
---
Continuous Gravitational Wave search Galactic Center lowFreq
x
x
---
---
Continuous Gravitational Wave search Galactic Center highFreq
x
x
---
---
Other settings
generic
home
school
work
Run Linux app versions built with LIBC 2.15
yes
yes
---
---
Run CPU versions of applications for which GPU versions are available
Run Linux app versions built with LIBC 2.15 yes yes
Run CPU versions of applications for which GPU versions are available yes yes
Allow non-preferred apps yes yes
....
If the first setting really was yes/yes at the time the work request was made, there may be an explanation for getting AVX tasks. Here are the relevant lines from the latest scheduler log for your machine that I've just looked at. I've truncated some information for clarity.
2017-11-10 10:11:53 [resend] [HOST#12523623] found lost [RESULT#695351059]: h1_0394.80_O1C...
2017-11-10 10:11:53 [version] Checking plan class 'AVX'
2017-11-10 10:11:53 [version] reading plan classes from file /BOINC/projects/EinsteinAtHo ...
2017-11-10 10:11:53 [version] plan class ok
2017-11-10 10:11:53 [version] Checking plan class 'LIBC215'
2017-11-10 10:11:53 [version] project prefs setting 'libc215' (1.000000) prevents using p ...
2017-11-10 10:11:53 [version] Best version of app einstein_O1Spot1Lo is 1.00 ID 989 AVX (5...
The first thing to note is that the scheduler is seeing 'lost' results. This can happen if you delete result entries in your state file (client_state.xml). I believe it also happens if you reset the project. The scheduler will notice on the next contact and will return them to your client even if that task is no longer 'allowed' by your preferences.
To stop the scheduler doing this, you need to abort the tasks (and continue doing so if it keeps sending you more lost tasks) so that the scheduler is informed that the tasks really are no longer required. In other words, to properly get rid of tasks, have your client tell the scheduler that they are aborted. If you're ever tempted to reset the project and don't want the current tasks back, you should abort them all before resetting.
The second thing to notice is that the scheduler is checking the new plan class LIBC215 but it can't be used because your preferences don't allow it. My guess is either the setting wasn't in force at the time of contact or it was in force and there is some bug preventing that setting from being evaluated correctly.
Here's what I would try.
Change the 2nd and 3rd settings in the group of three in the 'Other Settings' quote to no/no and save the changes. Don't give the scheduler any excuse to consider anything else other than the LIBC215 plan class.
Abort any AVX tasks that your client currently has.
If the aborted tasks aren't immediately returned, click 'update' to force the contact.
If you get more 'lost' AVX tasks, rise and repeat until they are gone.
If new tasks are allowed, you should get the LIBC215 plan class unless there really is a bug in how this is supposed to work. At least, the scheduler log showing how the scheduler handled the exchange should be interesting to read :-).
Actually, I don't use grub
)
Actually, I don't use grub here, having failed to get it to boot on this UEFI machine. I use systemd-boot and efibootmgr instead. And, this being Gentoo, I have to compile my own kernels, which is why I quoted the kernel help text. I don't see anything there about passing a boot-time kernel parameter as well.
Are you recommending vsyscall=emulate?
--
Rgds
Peter.
Yes, the new default is
)
Yes, the new default is "vsyscall=none" which breaks old applications and you need to activate emulation again in order to get the apps working. The EaH apps fail right at the start so if you get it working but still see the messages they can be ignored.
OK. Thanks Christian.
)
OK. Thanks Christian.
--
Rgds
Peter.
There is now a GW ("O1Spot1")
)
There is now a GW ("O1Spot1") application version that has been compiled on Ubuntu 10.04 with LIBC 2.15 and thus should fix this problem without enabling vsyscalls. As there is currently no BOINC Client that detects and reports the LIBC version, there is no way to automatically choose which app version to deliver to the clients. Instead there is a new project-specific setting "Run Linux app versions built with LIBC 2.15" that you have to enable manually. Please give it a try and see if it works.
While testing there is only an app version for the GW search, so you probably want to disable other applications (FGRP*) to prevent these from failing.
BM
Bernd Machenschalk
)
Did you really mean 10.04? That’s positively ancient (circa 2012) wouldn’t a more recent one be better?
BOINC blog
Bernd Machenschalk
)
Hello
Can you help me in configuring project to use LIBC215 version?
I have checked "Run Linux app versions built with LIBC 2.15" option in project settings. I also disabled all applications except "Continuous Gravitational Wave search Galactic Center lowFreq" and "Continuous Gravitational Wave search Galactic Center highFreq" as you sugest. Still all calculations try to run on AVX version and crash with segmentation fault.
When I look in project directory BOINC Client downloads only einstein_O1Spot1Lo_1.00_x86_64-pc-linux-gnu__AVX executable. There is no any other vesion like LIBC215.
Should I set any other option somewhere?
I run calculations on Linux Debian Testing, so kernel and other packages are quite new:
CPU type: GenuineIntel Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz [Family 6 Model 23 Stepping 10]
Number of processors: 4
Coprocessors: ---
Operating system: Linux Debian Debian GNU/Linux testing (buster) [4.13.0-1-amd64]
BOINC client version: 7.8.3
And here copy of my project settings:
Best regards
Thanks for trying this out.
)
Thanks for trying this out. Unfortunately I'm unable to help you today, but I will look into this on Monday.
BM
keiichi wrote:Should I set
)
If the first setting really was yes/yes at the time the work request was made, there may be an explanation for getting AVX tasks. Here are the relevant lines from the latest scheduler log for your machine that I've just looked at. I've truncated some information for clarity.
The first thing to note is that the scheduler is seeing 'lost' results. This can happen if you delete result entries in your state file (client_state.xml). I believe it also happens if you reset the project. The scheduler will notice on the next contact and will return them to your client even if that task is no longer 'allowed' by your preferences.
To stop the scheduler doing this, you need to abort the tasks (and continue doing so if it keeps sending you more lost tasks) so that the scheduler is informed that the tasks really are no longer required. In other words, to properly get rid of tasks, have your client tell the scheduler that they are aborted. If you're ever tempted to reset the project and don't want the current tasks back, you should abort them all before resetting.
The second thing to notice is that the scheduler is checking the new plan class LIBC215 but it can't be used because your preferences don't allow it. My guess is either the setting wasn't in force at the time of contact or it was in force and there is some bug preventing that setting from being evaluated correctly.
Here's what I would try.
If new tasks are allowed, you should get the LIBC215 plan class unless there really is a bug in how this is supposed to work. At least, the scheduler log showing how the scheduler handled the exchange should be interesting to read :-).
Cheers,
Gary.
Thanks for testing and
)
Thanks for testing and spotting this!
The configuration of the plan class was wrong and had been fixed.
Sorry for the inconvenience and the delay.
BM
You're most welcome! Thanks
)
You're most welcome!
Thanks for letting us know.
Cheers,
Gary.