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