Freeze on FPU exception with Athlon

The following small program (linked against glibc 2.1.3) reliably
freezes my system (Athlon Thunderbird CPU) with at least kernels
2.4.0-test10 and 2.4.0-test11-pre5. Even the SysRq keys do not work
after the freeze.

Older kernels (e.g. 2.3.40) seem to work. Any Ideas?

---------------------------------------

#define _GNU_SOURCE

#include <fenv.h>
#include <unistd.h>

int
main(void)
{
double a;
fesetenv(FE_NOMASK_ENV);
a = 1.0 / 0.0;
sleep(10);
return a;
}

---------------------------------------

--
Markus

__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Gratis zum Millionär! - http://10millionenspiel.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

In article <[email protected]>,

Are you sure sysrq doesn't work? Many distributions will disable the kernel printing to the console, or move it to console 7 or similar.

It would be really good to get the EIP trace of RightAlt+ScrollLock pressed a few times if you can try to see if you can use klogd to enable proper printk's.

The FP exception handling has certainly changed, but the changes should all have affected mainly just PIII kernels with XMM support enabled. An Athlon system should have been pretty unaffected. But I'll take a look if I see something obvious.

One thing to try: if interrupts really don't work for you (and if SysRq doesn't work, that may be the case), please test out a kernel that simply ignores irq13 by just commenting out the line

	setup_irq(13, &irq13);

in arch/i386/kernel/i8259.c. Does that make any difference? (irq13 shouldn't be used any more, it's horrible legacy crap, but we do want to support even horrible legacy systems).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

In article <[email protected]>,

It certainly doesn't happen for me on any of the machines I work with, but it wouldn't compile as-is for me, so I exchanged the FPU setting with a simpler

	asm("fldcw %0": :"m" (0));

which should do the equivalent (ie unmask divide by zero errors). Does that make a difference for you?

Can you try to figure out where it started happening? Ie try test9 and back too, to figure out what might be bringing it on...

I sure as hell hope this isn't an Athlon issue. Can other people try the test-program and see if we have a pattern (ie "it happens only on Athlons", or "Linus is on drugs and it happens for everybody else").

Thanks,

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I couldn't get it to freeze. I tried it with asm("fldcw %0": :"m" (0)) and with fesetenv() using gcc -lm to link it. I have glibc-2.1.2, egcs 2.91.66, and 2.4.0-test10.

Regards,
Adrian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi,
I am using test10-pre5 on Duron.

Same here except gcc-2.95.2 and glibc 2.13. I got an floating point expeption. No freeze here.

Greetings

Michael Meding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I've tried both variants (fesetenv and inline-asm) with glibc-2.1.3, 2.4.0-test11pre7 and an AMD Thunderbird. Neither does freeze, but both yield:

Floating point exception (core dumped)

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Compiler specific ?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

There's almost certainly more than that. I'd love to have a report on my asm-only version, but even so I suspect it also requires the 3dnow stuff, because I'm not able to trigger anything like this on any machines I have access to (none of them are AMD, though)

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hmm...

Linus, I've tried your latest asm-version with my Thunderbird, egcs-1.1.2 and 3dnow support compiled in. Several runs show no problems - the program runs and terminates gracefully.

-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I tried all three versions, and no freezes. I forgot to mention the tests were run on a model 2 Athlon (original slot K7, .18 micron). The kernel is compiled with 3dnow support.

Regards,
Adrian

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Apparently it isn't the stepping, as we have Athlon model 4's both showing it and not showing it. The motherboard seems to be the only real difference here, which is why I like the irq13 explanation more and more.

I've been wanting to get rid of irq13 anyway (some boards wire up USB and/or ACPI to irq13 and the fact that the FPU has claimed it makes those machines unhappy), so if the solution is to only check for irq13 on old i386 and i486sx machines and just leave it alone for newer CPU's, I won't complain.

Markus, can you make the irq13 test the first thing - don't worry about 3dnow as that seems to not be a deciding factor..

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Mine freezes with both versions of C versions, haven't tried the asm yet.
gcc-2.95.2 and glibc-2.1.3 both of which are compiled for 486.

===============processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 2
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 751.000719
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
features        : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 1500.77

-- Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I get Floating Point Exception (core dumped), but I needed to use the modified program below to keep GCC from optimizing the division away as a constant. This is on test11-pre5.

--------------
#define _GNU_SOURCE

#include <fenv.h>
#include <unistd.h>

double a =1.0, b = 0.0;
int
main(void)
{
double c;
asm("fldcw %0": :"m" (0));
// fesetenv(FE_NOMASK_ENV);
c = a / b;
sleep(10);
return a;
}
--------------
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 2
model name : AMD Athlon(tm) Processor
stepping : 2
cpu MHz : 748.000573
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
features : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1494.22

						Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I'm starting to suspect that it's really a combination of three things:
- 3dnow optimization (ie you have to compile the kernel with Athlon support)
- pending, but not yet noticed, FPU exceptions.
- a bug/feature in the kernel, where a process exit does not bother to clear the FPU, only marks it as "unused".

If I'm right, the proper test-program should be something like

	int main(int argc, char **argv)
	{
	        asm("fldcw %0": :"m" (0));
	        asm("fldz ; fld1 ; fdiv");
		sleep(1);
	        return 0;
	}

where it's important that we do not wait for the result of the fdiv, we just exit after having caused a pending exception (and you cannot do this reliably from C code - depending on compiler version and optimizations gcc may try to write the bad value back to memory etc).

Now, with the pending exception, do a 3dnow MMX memcpy() - which will clear the TS bit (because it decides that the FP state can be thrown away and doesn't need to do a full save/restore) and start using the FPU. Boom. Instant FP exception. With the exception handler deciding that nobody owns the FP state, and thus doing nothing sane.

If I'm right (and I'm _always_ right), the following patch would make a difference.

Markus?

Linus

----

@@ -643,6 +640,12 @@
 asmlinkage void do_coprocessor_error(struct pt_regs * regs, long error_code)
 {
 	ignore_irq13 = 1;
+
+	/* Due to lazy error handling, we might have false pending errors! */
+	if (!current->used_math) {
+		init_fpu();
+		return;
+	}	
 	math_error((void *)regs->eip);
 }
 

@@ -700,6 +703,12 @@
 	if (cpu_has_xmm) {
 		/* Handle SIMD FPU exceptions on PIII+ processors. */
 		ignore_irq13 = 1;
+
+		/* Due to lazy error handling, we might have false pending errors! */
+		if (!current->used_math) {
+			init_fpu();
+			return;
+		}	
 		simd_math_error((void *)regs->eip);
 	} else {
 		/*

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/