summary refs log tree commit diff stats
path: root/results/classifier/108/other/796
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/79632
-rw-r--r--results/classifier/108/other/79620285
-rw-r--r--results/classifier/108/other/79648065
3 files changed, 182 insertions, 0 deletions
diff --git a/results/classifier/108/other/796 b/results/classifier/108/other/796
new file mode 100644
index 00000000..d240dfbd
--- /dev/null
+++ b/results/classifier/108/other/796
@@ -0,0 +1,32 @@
+device: 0.910
+graphic: 0.758
+performance: 0.697
+PID: 0.674
+network: 0.653
+debug: 0.645
+socket: 0.639
+semantic: 0.551
+vnc: 0.543
+boot: 0.508
+files: 0.507
+other: 0.363
+permissions: 0.215
+KVM: 0.058
+
+make -j126 check failed in qemu@6.2.0 on ubuntu_aarch64
+Steps to reproduce:
+the issue
+
+```console
+[root@localhost build]#make -j126 check
+Running test fp-test-sqrt
+Running test fp-test-sub
+Running test fp-test-log2
+**
+ERROR:../tests/unit/test-qga.c:718:test_qga_config: assertion failed (err == ""): ("/home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: symbol lookup error: /home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: undefined symbol: g_unix_get_passwd_entry\n" == "")
+ERROR test-qga - Bail out! ERROR:../tests/unit/test-qga.c:718:test_qga_config: assertion failed (err == ""): ("/home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: symbol lookup error: /home/stage/root/spack-stage-qemu-6.2.0-532ksrh2smva65sb3ghqox222237khs5/spack-src/build/qga/qemu-ga: undefined symbol: g_unix_get_passwd_entry\n" == "")
+make: *** [Makefile.mtest:1472: run-test-182] Error 1
+make: *** Waiting for unfinished jobs....
+……
+```
+I don't know why happen,can you help me?
diff --git a/results/classifier/108/other/796202 b/results/classifier/108/other/796202
new file mode 100644
index 00000000..82a22653
--- /dev/null
+++ b/results/classifier/108/other/796202
@@ -0,0 +1,85 @@
+socket: 0.871
+graphic: 0.836
+other: 0.827
+boot: 0.813
+permissions: 0.812
+network: 0.805
+device: 0.803
+semantic: 0.794
+vnc: 0.793
+performance: 0.768
+files: 0.766
+PID: 0.733
+debug: 0.619
+KVM: 0.478
+
+Doing a 64 bit load from a 32 bit local APIC register is allowed
+
+Doing
+
+u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20;
+
+and later in an interrupt handler
+
+movq (lapic_idregister), %rcx
+movq (%rcx), %rcx
+
+in a linux kernel module works in qemu 0.13.91 but not on real hardware (it simply reboots).
+On real hardware only
+
+movl (%rcx), %ecx
+
+works (also in qemu).
+
+Commandline:
+qemu-system-x86_64 \
+		-kernel $LINUXDIR/arch/x86_64/boot/bzImage \
+		-hda $BUILDROOTDIR/output/images/rootfs.ext2 \
+		-append "root=/dev/sda rw rootfstype=ext2 maxcpus=4" \
+		-cpu phenom \
+		-smp 4 \
+		-gdb tcp::1234 \
+		-net nic -net user
+
+Guest:
+Vanilla Linux Kernel 2.6.37.6 64-bit with buildroot
+
+Mikael Pettersson from the linux kernel mailinglist told me it's an accepts-invalid bug in qemu.
+
+On Sun, Jun 12, 2011 at 4:03 PM, Robert Uhl <email address hidden> wrote:
+> Public bug reported:
+>
+> Doing
+>
+> u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20;
+>
+> and later in an interrupt handler
+>
+> movq (lapic_idregister), %rcx
+> movq (%rcx), %rcx
+>
+> in a linux kernel module works in qemu 0.13.91 but not on real hardware (it simply reboots).
+> On real hardware only
+>
+> movl (%rcx), %ecx
+>
+> works (also in qemu).
+
+Thank you for the report. Currently QEMU devices only provide access
+methods up to 32 bits, a 64 bit access is emulated with two 32 bit
+accesses. So it is not possible to handle a 32 bit access differently
+from a 64 bit one for now.
+
+So far this hasn't been considered to be a problem for x86, though it
+is clearly not correct for Sparc and Alpha. This report shows that it
+is necessary to add 64 bit access methods (or otherwise handle 64 bit
+accesses more realistically) since x86 is also affected.
+
+Adding the 64 bit method would be a major refactoring though and there
+are other designs possible.
+
+
+Triaging old bug tickets ... can you somehow still reproduce this problem with the latest version of QEMU (currently v2.9), or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/796480 b/results/classifier/108/other/796480
new file mode 100644
index 00000000..09735e3a
--- /dev/null
+++ b/results/classifier/108/other/796480
@@ -0,0 +1,65 @@
+performance: 0.722
+graphic: 0.704
+device: 0.655
+permissions: 0.448
+semantic: 0.373
+other: 0.354
+PID: 0.346
+vnc: 0.337
+debug: 0.269
+socket: 0.200
+files: 0.170
+boot: 0.116
+network: 0.110
+KVM: 0.093
+
+Addresses with 4GB differences are consider as one single address in QEMU
+
+THIS IS THE ISSUE OF USER MODE EMULATION
+Information about guest and host
+**********************************
+guest: 64 bit x86 user mode binary
+host: 32 bit Linux OS
+uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP
+architecture: intel64
+Bug Description
+****************
+for memory reference instructions, suppose I have two addresses in guest address space(64 bit)
+0x220000000
+0x320000000
+as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit)
+in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values.
+here is the program which i used to test:
+#include <stdio.h>
+#include <stdlib.h>
+#include <limits.h>
+#define SIZE 4294967298 /* 4Gib*/
+
+int main() {
+   char *array;
+   unsigned int i;
+
+   array = malloc(sizeof(char) * SIZE);
+   if(array == NULL)    {
+      fprintf(stderr, "Could not allocate that much memory");
+      return 1;    }
+    array[0] = 'a';
+   array[SIZE-2] = 'z';
+   printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]);
+  return 0;
+}
+I have 8 gib RAM
+I compiled this program on 64 bit linux  and run this on 32 bit linux with qemu
+QEMU command line and output
+**********************************
+$x86_64-linux-user/qemu-x86_64 ~/ar_x86 
+output: array[SIZE-1] = z,array[0] = z 
+Release information
+********************
+x86_64 binary is tested with latest release : qemu-0.14.1
+and with current development tree as well( live code of QEMU using git)
+
+Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+