| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Beta Testing
Forum: Beta Test Support Forum
Thread: FreeBSD - lf192... WUs fail but faah... WUs work |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 12
|
|
| Author |
|
|
Parusie
Cruncher Joined: May 11, 2007 Post Count: 10 Status: Offline |
I apologise, I must bother you again. All three FreeBSD 6.2 computers started the calculation as expected.
----------------------------------------(one with some difficulties as outlined in my previous thread) However, after some hours of calcualtion one computer aborted crunching with an error: *************************** Result Log <core_client_version>5.4.9</core_client_version> <message> process exited with code 2 (0x2) </message> <stderr_txt> 2007-08-03 18:53:32 [World Community Grid] Process creation (../../projects/www.worldcommunitygrid.org/wcg_hpf2_rosetta_5.20_i686-pc-linux-gnu) failed: Error -1 execv: No such file or directory </stderr_txt> *************************** after uploading of the WU and downloading of a new one, the calculation aborted immediately. I have tried it again and it failed again. The strange thing is that the first wrong WU as well as the other two WUs, which failed, are named "lf192....." The same computer (dual CPU) has finished a "faah.." successful (pending validation) and the other two FreeBSD computers are still crunching on "faah..." WUs without any issues. boinc_client is in /var/db/boinc the project folder /var/db/boinc/projects/www.worldcommunitygrid.org contains the required binaries poseidon# ls faah2023_d198n616_x2AZC_02_1_0 hpf2.avgE_from_pdb.gz faah2023_d198n616_x2AZC_02_1_1 hpf2.bbdep02.May.sortlib.gz faah2023_d198n616_x2AZC_02_AD4_parameters.dat hpf2.paircutoffs.gz faah2023_d198n616_x2AZC_02_d198n616.pdbqt hpf2.pdbpairstats_fine.gz faah2023_d198n616_x2AZC_02_d198n616_x2AZC_02.gpf hpf2.phi.theta.36.HS.resmooth.gz faah2023_d198n616_x2AZC_02_faah2023_d198n616_x2AZC_02.dpf hpf2.phi.theta.36.SS.resmooth.gz faah2023_d198n616_x2AZC_02_x2AZC.pdbqt hpf2.plane_data_table_1015.dat.gz faah_dat_linux_5.30.dat hpf2.sasa_offsets.txt.gz faah_image_linux_5.30.tga hpf2.sasa_prob_cdf.txt.gz hpf2.Paa.gz hpf2_5.20_lin_paths.txt hpf2.Paa_n.gz stat_v01.png hpf2.Paa_pp.gz wcg_faah_autodock_5.30_i686-pc-linux-gnu hpf2.Rama_smooth_dyn.dat_ss_6.4.gz wcg_faah_autodock_5.30_i686-pc-linux-gnu.so hpf2.SASA-angles.dat.gz wcg_hpf2_rosetta_5.20_i686-pc-linux-gnu hpf2.SASA-masks.dat.gz Does it cause you any trouble when I produce errors? If so I would stop the FreeBSD computers. I could provide root access to a 24/7 FreeBSD computer if this would help you. [Edit 2 times, last edit by Parusie at Aug 4, 2007 8:49:22 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I answered in your previous thread. You have damaged your installations by moving boinc_client. BOINC needs to run as a service (it will start automatically at startup).
I have found this guide invaluable: http://people.freebsd.org/~pav/boinc.html |
||
|
|
Parusie
Cruncher Joined: May 11, 2007 Post Count: 10 Status: Offline |
I still get errors when crunching "fl...." WUs. It does not help to reinstall as described on the page that you have suggested :-(
So I changed my profile and allow only FAA WUs, which work fine. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hi,
it seems that something with the hpf2 Linux executable is different compared to the other project's executables sent to us on FreeBSD. wcg_faah and wcg_dddt can be executed without problems but wcg_hpf2 fails: # pwd You can see that after setting ELF type to Linux hpf2 can be executed. That will work on BOINC 5.4.x, but on later versions (I'm running 5.8.17) it fails because file checksum do not match. For now I have disabled getting work for hpf2.. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hello jonsonn,
That will work on BOINC 5.4.x, but on later versions (I'm running 5.8.17) it fails because file checksum do not match. If you look at http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=10249 you will see that FreeBSD worked with BOINC 5.8 back in March. I think that your problem is being caused by something different. Could you give us some more information about your system and software and the errors caused by trying to run HPF2? Lawrence |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hi lawrencehardin,
I'll be happy to do so. I started using WCG on FreeBSD by the time I found this original thread you refer to. At that time it was possible to brandelf' the executable for hpf and it would work. At least that is how I remember it... Anyway, current state is like this: Attaching to WCG, it downloads FAAH, DDDT and HPF2. Everything works well, just HPF2 workunits fail and show "Computation error" right after start. "ELF binary type "0" not known." is printed to STDERR. Setting the executable to ELF type Linux solves that problem (see original post and the manpage for brandelf) and creates a new: file checksum doesn't match so BOINC client will delete the executable and re-download it. I tried to edit the .xml files and put in the new checksum but failed to find out how those checksums are generated. So I just disabled HPF2 for the time being.. Here is some more technical details: 6.2-RELEASE i386 with linux_base-fc4 installed and linux.ko loaded. Everything is in place, FAAH and DDDT work well. # pwd Again, to highlight the difference: wcg_faah_autodock_5.41_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped Seems we don't like the statically linked executable..? |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I've always had problems with HPF2 WU's on my FreeBSD machine with ELF as well. I'd asked but nobody knew at that time.
I set mine to FAAH and its been happy crunching those. Obviously its not a permenent fix but with that project set to run at least another year I'm hoping either BSD 7 or newer released of Boinc would fix it. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Have u tried DDDT on that client with failing HPF2?
----------------------------------------I'll ask the techs to have a look, no promises as the number registered with FreeBSD using the Linux science app is 98 momentarily. Added: There was a note in the back-room to say that the present HPF2 build is slightly different using something called gcc 4.0. Modifying it will be problematic in that if it is science related, 35,000 linux clients are exposed to a change.
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 1 times, last edit by Sekerob at Sep 17, 2007 6:33:37 AM] |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Sorry Lassies/Guys, don't shoot the messenger, but unless it was something innocuous it could be fixed, but it is not. Recommendation is to stick with FA@H and DDDT if it works and not even entertain AC@H as they are rare anyhow. The time investment to make it a proper port would not be viable.
----------------------------------------
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Setting the executable to ELF type Linux solves that problem (see original post and the manpage for brandelf) and creates a new: file checksum doesn't match so BOINC client will delete the executable and re-download it. I tried to edit the .xml files and put in the new checksum but failed to find out how those checksums are generated. So I just disabled HPF2 for the time being.. Here is some more technical details: 6.2-RELEASE i386 with linux_base-fc4 installed and linux.ko loaded. Everything is in place, FAAH and DDDT work well. Did you try settind kern.elf32.fallback_brand=3? It helps for me, but I encounter two other problems: - sometimes block computation does not finish, it displays as "rinning 100%", and stops eating CPU - there are SIGPIPE: write on a pipe with no reader, and block sent seems to be lost. |
||
|
|
|