1 files changed, 112 insertions, 0 deletions
diff --git a/results/classifier/118/none/672934 b/results/classifier/118/none/672934
new file mode 100644
index 000000000..6fbdb9e56
--- /dev/null
+++ b/results/classifier/118/none/672934
@@ -0,0 +1,112 @@
+user-level: 0.665
+permissions: 0.640
+PID: 0.606
+register: 0.575
+risc-v: 0.571
+semantic: 0.571
+debug: 0.562
+hypervisor: 0.549
+TCG: 0.532
+boot: 0.527
+network: 0.513
+arm: 0.512
+VMM: 0.503
+assembly: 0.493
+device: 0.482
+performance: 0.481
+ppc: 0.469
+files: 0.445
+virtual: 0.429
+peripherals: 0.429
+vnc: 0.410
+mistranslation: 0.406
+KVM: 0.404
+x86: 0.395
+socket: 0.392
+architecture: 0.382
+kernel: 0.346
+graphic: 0.291
+i386: 0.213
+
+FPU incorrect on Mac OS X
+
+I am using the 0.13.0 release version of QEMU on Mac OS X 10.6.4. I work for a university and the affected guest OS is our own research OS. I believe I found a bug in QEMU's FPU emulation, which only triggers on the Mac. You can reproduce the problem by booting the attached ISO image.
+
+Investigating the problem, I found that the lua interpreter in our loader component (called "ned") internally uses doubles to represent all lua-numbers. These doubles are showing completely wrong values on QEMU/Mac, resulting in the lua code not processing properly.
+
+I also attached a patch which fixes the problem for me. The attached ZIP-file also contains "before" and "after" screenshots. Note that booting the ISO on a real machine or on a Linux-QEMU always shows the correct "after" behavior. Only QEMU on the Mac exhibits the wrong "before" behavior without my patch. The patch might break other systems setting the CONFIG_BSD flag, so maybe the preprocessor should check for __APPLE__ instead to make the fix Mac-only.
+
+
+
+
+
+
+
+
+
+
+
+Looks like the ISO from comment #4 (thanks for attaching that one!) shows the correct behavior with up to date QEMU 2.7. Also, the affected softfloat code has been completely reworked in between (e.g. with commit cf67c6bad56d43e6d60), so I assume this has been fixed sometimes in the past years.
+
+I can confirm that recent QEMU works fine. Sorry, I forgot about this bug and did not update it.
+
+
+On Sep 12, 2016, at 5:03 PM, <email address hidden> wrote:
+
+> Looks like the ISO from comment #4 (thanks for attaching that one!)
+> shows the correct behavior with up to date QEMU 2.7. Also, the  
+> affected
+> softfloat code has been completely reworked in between (e.g. with  
+> commit
+> cf67c6bad56d43e6d60), so I assume this has been fixed sometimes in the
+> past years.
+>
+> ** Changed in: qemu
+>        Status: New => Fix Released
+>
+> -- 
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/672934
+>
+> Title:
+>   FPU incorrect on Mac OS X
+>
+> Status in QEMU:
+>   Fix Released
+>
+> Bug description:
+>   I am using the 0.13.0 release version of QEMU on Mac OS X 10.6.4. I
+>   work for a university and the affected guest OS is our own research
+>   OS. I believe I found a bug in QEMU's FPU emulation, which only
+>   triggers on the Mac. You can reproduce the problem by booting the
+>   attached ISO image.
+>
+>   Investigating the problem, I found that the lua interpreter in our
+>   loader component (called "ned") internally uses doubles to represent
+>   all lua-numbers. These doubles are showing completely wrong  
+> values on
+>   QEMU/Mac, resulting in the lua code not processing properly.
+>
+>   I also attached a patch which fixes the problem for me. The attached
+>   ZIP-file also contains "before" and "after" screenshots. Note that
+>   booting the ISO on a real machine or on a Linux-QEMU always shows  
+> the
+>   correct "after" behavior. Only QEMU on the Mac exhibits the wrong
+>   "before" behavior without my patch. The patch might break other
+>   systems setting the CONFIG_BSD flag, so maybe the preprocessor  
+> should
+>   check for __APPLE__ instead to make the fix Mac-only.
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/672934/+subscriptions
+>
+
+I have always suspected a FPU bug with qemu-system-ppc. Apple's audio  
+processing code uses floating point code a lot. As a possible result  
+the playback of audio on a Mac OS guest is very poor. Is this a  
+problem with certain floating point instructions? Also could you send  
+me the patch. I would like to test it. Thanks. 
+
+The patch is linked in my comment #5 above. However, the issue discussed here does not affect PPC, neither as the guest or host platform, so I’m not sure the patch applies to your problem.
+