Howdy,
     It works, as long as you don't run more than one instance.  On RHEL3 Kernel-2.4 on a P4 2.8GHz I tried both the SSE2-P4 and SSE3-P4.  With one instance of Seti running everything was ok.  But, since I'm running Hyper-Thread Boinc starts a second Seti task and instantly errors out with:


That is this result http://setiathome.berkeley.edu/result.php?resultid=510804716

Meanwhile the first, original, Seti workunit continues processing and eventually finishes.

The funny thing is, by playing with "suspend task" I can get BOINC to start a task for another project (Einstein in this case) and it will run ok in tandem with the first Seti task.  You just cannot run two Seti tasks simultaneously.

At this point I've completed one workunit http://setiathome.berkeley.edu/workunit.php?wuid=122308461.  Mine is the one for 11614 seconds.  The workunit hasn't validated at this point in time, still waiting for another result.  Hopefully it is ok.

But that still leaves the bigger question of why the shared memory fault.

Thanks again for all the effort you guys are putting into this work.
Best of Luck, and get some sleep.
Cheers, Chris

Howdy again,
     Well, another variation.  The new compile of SSE2-P4 runs a little better on a RHEL3 2.4 Kernel when used with Boinc 5.8.15 vs. 5.4.9 or 5.4.11 .  This was tested on two separate boxes, but the results were about the same.  On a Boinc 5.8.15 client when a series of Seti workunits are downloaded and work starts the first workunit runs ok, the second workunit crashes, but then the third workunit will run ok.  So, on a hyperthread cpu you can get two seti workunits running simultaneously.   This is better than on a Boinc 5.4.9 client where only the first Seti workunit will run, and any attempt to start another workunit will crash (note my previous post in this thread).
     Continuing work on the Boinc 5.8.15 client, when one of the Seti workunits finishes, the next workunit will crash, but then a second attempt to start another workunit will run ok.  Obviously, I'm not continuing at this time with this new code on the 2.4 Kernel, don't want to "error out" a bunch of workunits.  Hopefully, this adds to the understanding and leads to a solution for the problem.

Two of the error workunits are:
http://setiathome.berkeley.edu/result.php?resultid=511457534
and, http://setiathome.berkeley.edu/result.php?resultid=511457667

The relevent log outputs:

and,

So, on a 2.4 Kernel with Boinc 5.8.15 basically the same shared memory fault, but not as often as with Boinc 5.4.9 (or 5.4.11).

I'm an experimental scientist so I'm  always  looking for more data.  So, here are a couple of the "successful" workunits for completeness, maybe they will be of some use.
http://setiathome.berkeley.edu/result.php?resultid=511457685
http://setiathome.berkeley.edu/result.php?resultid=511457749

If I can help speed up the work I'll be happy to test anything you want to throw my way.  We can see if it sticks to the wall.

Ciao, Chris

Thanks for your replies guys,

maybe we can figure out something for the future. However, 2.4.x kernel systems really won't be a major focus; I do realize this is a bother for people (I still have some 2.4 systems myself running Slackware, but they do just fine with the 2.2B apps).

The scheduling problems with BOINC are interesting; for me, 5.8.x works as well as 5.4.11 on two Pentium-D boxes. The only errors I had there were because the initial SSE3-P4 version had an accuracy problem.

We'll see what we can figure out, and the sources plus some info on how to get the thing compiled will be online soon.

Regards,
Simon.

Howdy all,
     This is to report that the problem I reported earlier in this thread is no longer a problem. 

     I.e. I had seen, on multiple boxes, errors when more than one instance of the new Seti 2.2B code were run simultaneously ( with hyper threading on these boxes).  What exactly was the cure, I don't know.  After a recent update of the RHEL3 system software I noted that there had been an update of glibc to 2.3.2-95.50.  I do not know if this new glibc package is the cure, but it triggered my curiosity to retry the 2.2B code again on these RHEL3 boxes.  And, Viola, everything works great.  So, on 4 different RHEL3 systems I've now run the 2.2B code with no problems.

     I still don't know why I had problems with the 2.2B code on RHEL3 boxes while michael37 (see preceding post in this thread) did not.  I would hazard a guess that maybe he had more updated systems at that time, since I have to test new updates for compatibility with our software applications before installing them.

     Anyway, I'm now pumping out data faster than ever with the 2.2B code running on all the boxes (except an old SGI and SUN).  And when the opportunity arises I'll install the even faster 64bit code on all my Linux boxes.

Thanks again for all the effort.  Czesc, Chris

It does require GLIBC 2.3.4, can you upgrade you host ?

Simon,

I double checked today, kernel-2.4 version gave same error, seems like it does require glibc-2.3.4.
Is there any particular reason not supporting glibc-2.3.2 in this version?

P.S.
I had tried a few other downloads and they all support glibc-2.3.2 for kernel-2.4 version, only this one is the exception.