RE: Floating point corruption: followup

The simple answer is to run openssl genrsa in a while loop redirecting
stdout and stderr ot null, while running your code that uses the rotating fp
registers (specifically f32-38) on every processor...
(a context switch must occur)

The openssl needs to be one using the ia64 hand coded assembly routines.

A good program to demonstrate the problem is HPL with MKL or goto math libs,
or 
Compile the following with ecc -O0

#include<stdio.h>
 
 int main(void)
 {
         long i;
         double sum, dummy;
 
         for (i=0; i<100000000; i++)
         {
                 dummy= 1;
                 dummy /= 3;
 
                 sum += dummy;
         }
         printf("%lf\n",sum);
 }

Run one instance per processor while the openssl code is running in the
background. Watch the results... 
(it can be shown with gcc, but this is easier)


If you have any trouble, please feel free to contact me.
Mike

-----Original Message-----
From: digiovanni, lucio [mailto:[email protected]] 
Sent: Friday, May 09, 2003 12:49 PM
To: '[email protected]'
Subject: RE: Floating point corruption: followup

I am having an issue with data corruption and do not know if it is the same
problem.
Can you send (or point me to) a way to demonstrate your problem?

Thanks,
-Lu 

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, May 08, 2003 6:01 PM
To: [email protected]
Subject: RE: Floating point corruption: followup


It looks like there are 2 confirmed problems...
One is the use of FPSWA version 1.12 on some codes not flushing to zero.
(the result appears to be wrong answers in computational codes)
Some firmware versions have fpswa 1.09, but the elilo rpm or fpswa rpm
updates the fpswa via an efi program at each boot time.

The second more serious issue has been narrowed down to a linux kernel
problem. I believe the solution will be to patch the system.h file in the
kernel source. It appears that clearing mfh even though you wrote to upper
floating point registers can lead to another process not having it's upper
registers restored. 
It turns out that the IA64 assembly code for ssl does this, and using ssh on
a machine with at least 1 process per processor can quickly demonstrate data
corruption in floating point arithmetic merely by logging on to the machine
via ssh. (you will have to be using the Intel compiler or
-mfixed-range=f1=31 with gcc)

The problem did not occur with the switch_to code in the 2.4.9 kernel, but
does in the 2.4.19 and 2.4.20 kernel.

It would be interesting to see the effect you could have on ssl by having
code that zeros the registers and clears mfh.

Anyone that uses these machines for scientific computing should take this
pretty seriously... This was discovered at first by running HPL (which
verifies it's results) and we were getting wrong results because the passwd
file was getting copied in via scp while it was running. We were able to
find that virtually all of the codes that were compiled to use upper fp
registers or used libraries that did, were producing corrupted results.

If you are interested in demonstrating this, I can provide some example
instructions.


Thanks
Mike

-----Original Message-----
From: David Mosberger [mailto:[email protected]] 
Sent: Thursday, May 01, 2003 5:12 PM
To: [email protected]
Subject: RE: Floating point corruption

>>>>> On Thu, 1 May 2003 17:15:57 -0500, [email protected] said:

  Mike> One of the 2 kernels that shows the problem has that call in
  Mike> it...  This may be related to upper registers at least in the
  Mike> f32-f38 range (maybe more)

Hmmh, that doesn't ring a bell then. 

	--david



_______________________________________________
ia64-list mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/ia64-list





_______________________________________________
ia64-list mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/ia64-list