That I think would require a version control failure... how likely is that? Nope, it's still the same 6.19 for Linux. I've stuck to the 2.6.32 kernel for Linux, which is 10.04.1 LTS (Long Term Support). The ultra minor update is now on something like 2.6.32.25. CEP2 keep on churning fine, max 2 of 4 cores, with HPF2, HCMD2, C4CW on the side. Flip flopping the device profile once a day incrementing the cache slowly to get the right mix, then set cache back to 1 day. It's reasonable handleable as the run times are now in general 8.5+ hours (still 30-40 minutes overhead per CEP2 task). Don't need to buffer too many to get through a couple of days and since my client is set to jump the repairs ahead on top, seem to be staying with average return times below 2 days... to get more repair work. Have the impression there are not very many R++ devices on Linux, as the ratio is < 4 day deadlined tasks is nearing 20%, a mix of selected sciences, but mostly CEP2, which then run fine...old Q6600, stock speed.

edit: both the currently running CEP2 jobs are repairs ;O)

Repair WU's are simply replacement WU's that are sent out to a known reliable host (see the FAQ's for details), to replace WU's that either haven't been returned in time, errored out/aborted, or are verification WU's.

The techs look at there their periodic reports to see what stands out. What logs to send? They have the result log of course, and any of the stdxxxxxx.txt log files that hold pointers are of interest. Maybe the Linux event log shows something, but don't ask me presently how to get there. Not done this or researched myself.

Maybe entirely unrelated saw a bug report on NVidia driver 260.19.06 and all GPU tasks failing. My host got them, but all GPU crunching functions are disabled in the the cc_config.xml

Post a full Result log of such a result with the relative CPU and Elapsed times annotated. If time gets lost, something that was reported early in the project, techs aware, then the actual CPU times as best monitored from BOINCTasks or an old BOINC Manager, 6.2.28 or earlier, should display skipping back and % progress retreat, which checkpoint_debug logging switched on.

Result logs you find by clicking on the links in the Status column of the Result Status page.

<checkpoint_debug> logflag has to be added to the cc_config.xml file. By default that file already exists on Linux in the /var/lib/boinc-client directory for Lucid. Don't know where is goes for other distros. How to FAQ: http://boinc.berkeley.edu/wiki/Cc_config.xml