Bebul

We were able to reproduce the problem on the Windows XP. Work in progress... ---------- Post added at 12:41 ---------- Previous post was at 12:13 ---------- There is a fixed Patch.exe version of the latest OA Beta Patch. It is the ARMA2_OA_Build_108074.zip. Tell me, whether the installation issues are fixed, please. Thx.

Does the installation report the "%1 is not a valid win32 application" error before the patching started of somewhat during it? Can somebody with this issue try to: 1. unzip the *.zip file to get the exe 2. rename the exe to *.7z and unpack it to get three other exe files 3. run the patch exe itself Does the patch exe complain about "%1 is not a valid win32 application" too? (Only to eliminate the issue is inside 7z SFX?)

Thank you for your research. I have believed hard it cannot work on Windows servers too but you were right. I have fixed it. Not sure how it would cooperate with "old" windows clients, but it could hopefully work. Tests are promissing. Edit: here you are ftp://downloads.bistudio.com/arma2.com/update/a2oa-server-1.60.89986.tar.bz2

We should still wait whether everything would work as expected. Was a pleasure to work with your fast and precise response, thank you.

Looks like even 2 times faster compared to your patch ;-)

And here you are ftp://downloads.bistudio.com/arma2.com/update/a2oa-server-1.60.89362.tar.bz2 Please test and report Heureka xor Bad Luck :butbut:.

Yeah! That explains a lot. Thank you. I will prepare something and distribute it on Monday.

Would be nice to test once again, whether the change to CLOCK_MONOTONIC has helped at least a little (8min -> 5min). Can you upload the huge strace log of PATCHED older version too? The internet is full of clock_gettime + gettimeofday + futex looping, but I was not lucky to find any solution. So, probably, it is really some timing or race bug in linux engine code...

Are you sure? Looks like both are running almost the same time. FYI, your PATCH changes the following function: struct timespec *CalcTimeout(unsigned long timeout,struct timespec &ts) { if (timeout==(unsigned long)-1) return NULL; struct timeval now; gettimeofday(&now, NULL); unsigned long usec = now.tv_usec + timeout%1000*1000; ts.tv_sec = (now.tv_sec + timeout / 1000) + usec / 1000000; ts.tv_nsec = usec % 1000000 * 1000; //<-- you change it to ...*2000; in your PATCH return &ts; } The return value is used for thread synchronization purposes through pthread_cond_timedwait. So ts.tv_nsec is set from the fraction of second to the twice of its original value! Any ideas why it can make the two competing threads run faster? Edit: I am convinced this CalcTimeout is called mostly with timeout=0, which can be interpreted as pthread_cond_timedwait should return immediately. But after your patch, it would typically wait little or longer. I suppose both clock_gettime and futex are called from pthread_cond_timedwait and to tell the truth I am confused their calls counts are so low...

Ok, still very bad. :( Can you provide us the following, please? 1. check, using strace, there are clock_gettime instead of gettimeofday in new version (no need to wait until server starts, only check) 2. revert to older previous version (with gettimeofday in strace) and a) start it with strace and count the number of gettimeofday inside the strace log b) the same as in a) but hack it using your smart hotfix The question is, how much the counts of gettimeofday differs in a) vs b) ?

It has shown to be somewhat hard. In fact, your hexedit hotfix is really surprising. I have tried to use different implementation of Timeout calculation. Soppa, can you try this version, please? ftp://downloads.bistudio.com/arma2.com/update/a2oa-server-1.60.89343-testVer.tar.bz2 Backup your older version first, this one would be harder to hexedit (different implementation, no 1000 multiplication), but who knows, it could fix your problem...

Looks like CentOS specific problem. http://bugs.centos.org/view.php?id=3996 Edit: probably not CentOS specific. We would need to detect synchronization of what makes the server busy. Will try to prepare some linux server with multiple debugging opportunities for you...

Good job! The best would be if we can distribute new linux server version with some timeout changed (two times enlarged) and you would test it? The version is ready on ftp://downloads.bistudio.com/arma2.com/update/a2oa-server-1.60.89244.tar.bz2 2Soppa: Can you test whether your server starts faster with the fix provided?

Hi, in order to find + understand + fix the never green linux servers we need to know the following: When some Win32 server works and is GREEN, are you sure the very same copy of its content on linux is not GREEN? I mean, is it really the same, with no BAF and PMC folders present on Win32 installation (because linux cannot work with BAF/PMC)? Edit: another question is: are such Linux servers yellow for all players regardless whether have BAF/PMC installed or not?

You are right! There is nasty BUG crawling through all your joysticks whenever the number in the left column of RPT diagnostics was not continuous, such as Detected Joystick: T.16000M 0 ... X Axis [1,30] 1 ... Y Axis [1,31] 5 ... Z Rotation [1,35] 6 ... Slider [1,36] Detected Joystick: Logitech Extreme 3D Pro USB 0 ... Osa X [1,30] 1 ... Osa Y [1,31] 5 ... Rotace Z [1,35] 6 ... Posuvník [1,36] Detected Joystick: Logitech Extreme 3D 0 ... X Axis [1,30] 1 ... Y Axis [1,31] 5 ... Z Rotation [1,35] 6 ... Slider [1,36] Testing the fix atm.