Hi,
I noticed that the proll.patch on the pc-bios directory is not
the latest patch. It does not include the SMP support.
How to get the latest version?
--
You can't do something you don't know, if you keep on doing what you do
know. by F.M. Alexander
__
I noticed that the proll.patch on the pc-bios directory is not
the latest patch. It does not include the SMP support.
How to get the latest version?
For example:
http://marc.theaimsgroup.com/?l=qemu-devel&m=113480779129317&w=2
and
http://marc.theaimsgroup.com/?l=qemu-devel&m=113480643124728&w
hi
qemu 0.8.1 (0.8.0, too) fails to compile on x86_64 if sparc-user is
enabled:
gcc-3.3 -Wall -O2 -g -fno-strict-aliasing -I. -I..
-I/var/tmp/fst/src/qemu-0.8.1/target-sparc -I/var/tmp/fst/src/qemu-0.8.1
-I/var/tmp/fst/src/qemu-0.8.1/linux-user
-I/var/tmp/fst/src/qemu-0.8.1/linux-user/sparc -D_G
The OpenBIOS part sounds interesting/promising.
Once it is close to ready, let me know and I'll test/try it.
On May 19, 2006, at 10:28 AM, Blue Swirl wrote:
I noticed that the proll.patch on the pc-bios directory is not
the latest patch. It does not include the SMP support.
How to get th
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 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 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
Hi,
this patch fixes several bugs in mips-defs.h:
* Using enum for MIPS_R4Kc, MIPS_R4Kp does not work as expected,
because the C preprocessor does not know these values. It will
always use the branch for MIPS_R4Kc - independent of MIPS_CPU.
* More important is the value of the CP0 config reg
