>I got pretty much all the manuals from Intel's site that are available. Can
>you give me a reference to the appropriate section?! (just in case you know
>which one to search ;-)

The link http://www.intel.com/design/Pentiumiii/ is the top level for Intel
Pentium III processor docs. I think chapter 7 of volume 1 has all the FP
stuff. You might see if there is a specific errata for MMX-Pentium's (a
very different processor than the PentiumPro/II/III's). As the Pentium
doesn't do out of order execution, and the newer processors do

>Hm ... how about extending the (already existing) exception handler to
>handle floating point exceptions by masking the exceptions again and resume
>as usual?! Do you know if FPU exceptions are always resumable?!

That seems possible. I'm not sure things like FP stack overflow are
resumable, as it indicates some sort of code generation error. Figuring out
exactly what happened could also involve some ugly Intel specific code.
Seems like there was a default FP exception handler around.

>Guess we should be able to extend the exception handler to handle these
>problems as well, shouldn't we?!

My initial suggestion would be we write a little exception handler that
dumps the full FP context to a file when it faults.The exception context
record has the fields: ControlWord, StatusWord, and TagWord in the
FloatSave subrecord which should tell us the MMX state and exception mode.
This will not fix it, but will give us more data on systems that are
failing and have no low-level debugger available. I'd hate to implement a
solution to a problem that isn't the real problem.

Finding what's common in the systems that fail would also be appropriate.
It's my understanding only a few machines are showing this problem? It
seems like the data points are failures on a Win98 (some unknown version)
and a Win95 (also some unknown version) system. One of which has a sticker
claiming a MMX-Pentium processor. As the problem seems to not be widespread
(???), finding the common components to these two machines seems especially
important. 

<warning, cynic mode on>

A "Windows" PC with an Intel processor describes millions of potential
configurations. Many Windows software developers accept their product will
not run correctly on a few percent of the systems out there. They figure
not pissing off 97% if their customers is pretty good. Some software may
require VERY specific configurations, like a Pentium III processor of at
least 500 Mhz, DirectX 7.0 installed, and Win98 Second Edition (probably
only a fraction of a percent of all "Windows" machines, but maybe 20% of
all NEW machines). Some software will not work with certain
software/hardware installed, like a new "Bugs-Are-Us Internet compatible
thingy", which just sold 3 million units because of it's $25 million
marketing program. 

Win2000 (which is now released to manufacturing for February shipment)
continues the upgrade treadmill. My experience is MANY Win32 programs you
now have will not run correctly on Win2000. As a user, I find this
extremely annoying, as a software company owner a whole new round of
software upgrade revenue will happen, keeping a vast number of developers
fully employed.

<cynic mode off>

- Jan