>> Actually, it works on a Celeron but fails on a P5. This is caused by the
>> following bug suite (in approximately historical order):
>> 1) IRQ13 interface was broken as designed.
>> 2) Intel F00F bug.
>> 3) Probe for (1) is not very well implemented. It hacks on the idt[]
>>global to conte
> Actually, it works on a Celeron but fails on a P5. This is caused by the
> following bug suite (in approximately historical order):
> 1) IRQ13 interface was broken as designed.
> 2) Intel F00F bug.
> 3) Probe for (1) is not very well implemented. It hacks on the idt[]
>global to context swi
>>> JFYI - don't want us getting *too* complacent with -current now, do we? :-)
>>
>>Floating point exceptions are also broken, they always behave like
>>masked, even if you unmask some explicitly with fpsetmask().
>>
>>Even worse, a wrong result is returned if an exception had to be
>>thrown, whil
>> JFYI - don't want us getting *too* complacent with -current now, do we? :-)
>
>Floating point exceptions are also broken, they always behave like
>masked, even if you unmask some explicitly with fpsetmask().
>
>Even worse, a wrong result is returned if an exception had to be
>thrown, while the r
In <17751.927941...@zippy.cdrom.com>, Jordan K. Hubbard wrote:
[...]
> JFYI - don't want us getting *too* complacent with -current now, do we? :-)
Floating point exceptions are also broken, they always behave like
masked, even if you unmask some explicitly with fpsetmask().
Even worse, a wrong r
