Am Donnerstag, 18. Mai 2006 18:16 schrieb Joerg Platte:
Hi!
Here is a patch fixing the problem by calling save_state before all possible
fpu-interrupts.
regards,
Jörg
--- translate.c 2005-11-22 00:33:12.0 +0100
+++ translate.c.new 2006-05-22 20:40:07.0 +0200
@@ -982,6 +982,7 @@
Am Montag, 22. Mai 2006 21:12 schrieb Joerg Platte:
Hi!
> PS: Booting a normal SPARC-Image with init, hotplug, ... seems to work now
> much better than before. There is no bash segfault any more:
Shit, the bash still not works (I forgot the bash symlink pointing to a
dash :-). But programs using
Am Montag, 22. Mai 2006 19:51 schrieb Joerg Platte:
> Am Freitag, 19. Mai 2006 21:14 schrieb Blue Swirl:
Hi!
> This re-execution of the same tb could explain my discovered behavior of
> the FPU programs.
A "save_state(dc);" call was missing before all invocations
of "gen_op_trap_ifnofpu();" in t
Am Freitag, 19. Mai 2006 21:14 schrieb Blue Swirl:
Hi!
I added some debug output to the do_interrupt function. Maybe I'm totally
wrong, but env->pc is set some times to the same value again and again. And
other debug output indicates, that sometimes a portion of code containing an
FPU instructi
Am Freitag, 19. Mai 2006 21:14 schrieb Blue Swirl:
Hi!
> I'd still check the ld/stfsr implementation. The V8 spec says that stfsr
> _may_ zero the ftt field in fsr and what you describe sounds like the
> trapping happens too often. Just add env->fsr &= ~FSR_FTT_MASK into
> op_stfsr.
I already log
I've checked and changed a lot of code inside the kernel and in qemu and
added
debbugging output. The crash is more or less reproducible and the program
crashes after 2-3 FPU disabled traps somewhere inside the libc init
routines.
The FPU instructions cannot be the problem, because I disabled t
Am Donnerstag, 18. Mai 2006 19:53 schrieb Blue Swirl:
> >I've checked a lot of the executed instructions in qemu and cannot find
> > any problems up to now. Does somebody else has an idea what to check? The
> > test program simply adds two float variables (fadds-instruction) in a
> > loop and this
Am Donnerstag, 18. Mai 2006 19:53 schrieb Blue Swirl:
> >I've checked a lot of the executed instructions in qemu and cannot find
> > any problems up to now. Does somebody else has an idea what to check? The
> > test program simply adds two float variables (fadds-instruction) in a
> > loop and this
I've checked a lot of the executed instructions in qemu and cannot find any
problems up to now. Does somebody else has an idea what to check? The test
program simply adds two float variables (fadds-instruction) in a loop and
this crashes the program reproducible.
Some instructions trap when FPU
Hi!
I've some problems with qemu-system-sparc and programs using floating point
instructions. Each time at least two floating point programs are started in
qemu simultaneously, one or both are killed by the linux kernel with a SIGSEV
signal (sometimes because of a corrupted stack or invalid reg
10 matches
Mail list logo
