Re: FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
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 switch some IDT entries. 4) Fix for (2) is not very well implemented. It moves the IDT without hiding idt[] from (3). 5) Rev.1.55 of sys/kernel.h disturbed the probe order so that (4) is done before (3). This breaks the IDT context switching if the F00F fix gets installed. npx traps and interrupts end up being serviced by the dummy probe routines. Do you record this stuff anywhere? I think we should have a Bruce's nits page so this stuff isn't forgotten. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
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 switch some IDT entries. ... Do you record this stuff anywhere? I think we should have a Bruce's nits page so this stuff isn't forgotten. Usually not. I can regenerate it on demand :-). Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
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 result is returned if an exception had to be
thrown, while the result is right for masked exceptions.
#include stdio.h
#include stdlib.h
#include machine/floatingpoint.h
int main(void)
{
fpsetmask(0);
fprintf(stderr, I want no exception, but an exception value\n);
fprintf(stderr, res: %g\n, atof(1.0) / atof(0.0));
fpsetmask(FP_X_INV|FP_X_DNML|FP_X_DZ|FP_X_OFL|FP_X_UFL);
fprintf(stderr, I want an exception. Or at least an exceptional value\n);
fprintf(stderr, res: %g\n, atof(1.0) / atof(0.0));
fprintf(stderr, I didn't get one!\n);
return 0;
}
output on -current:
I want no exception, but an exception value
res: Inf
I want an exception. Or at least an exception value
res: 1
I didn't get one!
output on anything else:
I want no exception, but an exception value
res: Inf
I want an exception. Or at least an exception value
Floating point exception (core dumped)
Martin
--
%
Martin Cracauer craca...@cons.org http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
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 result is right for masked exceptions. This seems to have fixed itself: May 23 kernel: fails May 24 kernel: works May 28 kernel: works For the failing case, the FPU seems to be working properly but no CPU exception 16 is received for the unmasked FPU exception, and CR0_TS is in an unusualy state (not set) at the end of another test program. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
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 result is right for masked exceptions. This seems to have fixed itself: May 23 kernel: fails May 24 kernel: works May 28 kernel: works 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 switch some IDT entries. 4) Fix for (2) is not very well implemented. It moves the IDT without hiding idt[] from (3). 5) Rev.1.55 of sys/kernel.h disturbed the probe order so that (4) is done before (3). This breaks the IDT context switching if the F00F fix gets installed. npx traps and interrupts end up being serviced by the dummy probe routines. The easiest fix is to change the probe order. The F00F fix should never have been attached to proc0 initialisation. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Interesting bogons from last night's 4.0 snapshot.
Bogon #1: Userconfig doesn't appear to work - change anything at all and you're looking at a kernel panic when you exit. Hmmm! Bogon #2: Correcting Natoma for non-SMP configuration message on SMP boxes is now printed twice (once for each CPU? :). Bogon #3: bt_isa_probe: Probe failed for card at 0xNNN Where NNN is 6 different addresses. The driver should never be this chatty unless bootverbose is set. JFYI - don't want us getting *too* complacent with -current now, do we? :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
