Summary pretty much says it as it is. I think that the boinc ebuild should check for the kernel option to spare anyone else having the same issue. I have cobbled together an ebuild with such a check and will attach it shortly. (If this is deemed not to be needed, at least I will document this problem here so that others may find it useful.) This is what actually happened: I had set CONFIG_LEGACY_VSYSCALL_NONE in my kernel, but found that my boinc proccess were now dieing - I was unable to process any work units from www.worldcommmunitygrid.org. The sympton was lines such as: "Output file MCM1_0021915_8507_2_r392872912_0 for task MCM1_0021915_8507_2 absent" in the boinc manager event log. When I tried running the wcgrid binaries directly they simply failed with a "Segmentation Fault" message. I then quickly tracked down the real cause of the problem in dmesg: wcgrid_mcm1_7.3[13826] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffe82a622d8 ax:ffffffffff600400 si:100 di:0 Without vsyscall mapping, bionc projects (at least from wcg) do not work.
Created attachment 429416 [details] boinc-7.6.31-r1.ebuild An updated ebuild with a pkg_setup check for relevant VSYSCALL mapping option.
That is interesting, I will look into it.
You only check for CONFIG_LEGACY_VSYSCALL_NONE, and print the warnings if this is set. However, my config looks like this and all projects from the grid work just fine: -------- CONFIG_X86_VSYSCALL_EMULATION=y # CONFIG_LEGACY_VSYSCALL_NATIVE is not set # CONFIG_LEGACY_VSYSCALL_EMULATE is not set CONFIG_LEGACY_VSYSCALL_NONE=y -------- So I daresay all three (CONFIG_X86_VSYSCALL_EMULATION, CONFIG_LEGACY_VSYSCALL_NATIVE and CONFIG_LEGACY_VSYSCALL_EMULATE) are in order.
Hmmm... The help text for CONFIG_X86_VSYSCALL_EMULATION says: -------- With this option set to N, offending programs will just segfault, citing addresses of the form 0xffffffffff600?00. -------- As this fits, I think both options are in order.
After some tests I found out that either config option is in order to make all projects work. I have created a pull request with fixed ebuilds here: https://github.com/gentoo/gentoo/pull/1374
Thanks for investigating Sven.
The fixed ebuilds are merged into the portage tree.
I am re-opening this, because I have some bad news. It seems living with only CONFIG_X86_VSYSCALL_EMULATION is not always enough. While everything worked when I investigated this, I had four new projects downloaded a couple of minutes ago that were cancelled right away with a "calculation error". Those were "Rosetta Mini", "FightAIDS@home", and two were "Mapping Cancer Markers". gdb shows a segnmentation fault at: 0xffffffffff600400 in ?? And that is exacly the VSYSCALL area.
I have created a new pull request https://github.com/gentoo/gentoo/pull/1422
The PR is merged, and this issue should be (finally!) resolved. Thank you for your patience!
