restructure results

4 files changed, 0 insertions, 328 deletions

diff --git a/results/classifier/118/semantic-ppc/1038 b/results/classifier/118/semantic-ppc/1038
deleted file mode 100644
index 9c0756188..000000000
--- a/results/classifier/118/semantic-ppc/1038
+++ /dev/null
@@ -1,71 +0,0 @@
-ppc: 0.993
-semantic: 0.944
-architecture: 0.876
-TCG: 0.851
-KVM: 0.827
-device: 0.819
-performance: 0.799
-graphic: 0.780
-PID: 0.753
-mistranslation: 0.736
-kernel: 0.617
-vnc: 0.617
-network: 0.606
-register: 0.592
-files: 0.526
-arm: 0.526
-risc-v: 0.452
-socket: 0.430
-boot: 0.429
-permissions: 0.407
-hypervisor: 0.399
-debug: 0.389
-x86: 0.384
-i386: 0.361
-user-level: 0.314
-assembly: 0.306
-peripherals: 0.292
-VMM: 0.244
-virtual: 0.232
---------------------
-ppc: 0.999
-semantic: 0.668
-hypervisor: 0.563
-virtual: 0.450
-architecture: 0.167
-kernel: 0.119
-register: 0.058
-debug: 0.033
-PID: 0.021
-device: 0.021
-files: 0.020
-user-level: 0.019
-performance: 0.016
-socket: 0.012
-TCG: 0.009
-assembly: 0.007
-peripherals: 0.006
-VMM: 0.005
-risc-v: 0.004
-boot: 0.004
-permissions: 0.003
-network: 0.002
-graphic: 0.002
-KVM: 0.002
-vnc: 0.002
-mistranslation: 0.001
-arm: 0.000
-x86: 0.000
-i386: 0.000
-
-ppc 'max' CPU model is unlike the other targets 'max' CPU model
-Description of problem:
-On most targets the 'max' CPU model is either equivalent to 'host' (for KVM) or equivalent to all available CPU features (for TCG).
-
-On PPC64, however, this is not the case. Instead the 'max' model is an alias of the old '7400_v2.9' and simply doesn't work.
-
-This is confusing. At the very least the 'max' model alias should be deleted. Ideally a proper replacement would be introduced that matches semantics on other arches.
-Steps to reproduce:
-1. qemu-system-ppc64 -cpu max
-
-should be equiv to '-cpu host' or should expose all TCG features.
diff --git a/results/classifier/118/semantic-ppc/1681404 b/results/classifier/118/semantic-ppc/1681404
deleted file mode 100644
index 7473559e1..000000000
--- a/results/classifier/118/semantic-ppc/1681404
+++ /dev/null
@@ -1,86 +0,0 @@
-ppc: 0.947
-device: 0.907
-VMM: 0.832
-semantic: 0.814
-graphic: 0.792
-PID: 0.725
-performance: 0.723
-vnc: 0.634
-kernel: 0.633
-files: 0.619
-network: 0.614
-peripherals: 0.609
-register: 0.575
-architecture: 0.548
-TCG: 0.537
-socket: 0.521
-boot: 0.510
-hypervisor: 0.452
-mistranslation: 0.452
-risc-v: 0.431
-arm: 0.414
-permissions: 0.376
-virtual: 0.353
-user-level: 0.345
-debug: 0.315
-assembly: 0.301
-i386: 0.216
-x86: 0.205
-KVM: 0.130
---------------------
-ppc: 0.984
-debug: 0.933
-TCG: 0.865
-boot: 0.411
-device: 0.405
-register: 0.382
-PID: 0.313
-files: 0.234
-VMM: 0.177
-semantic: 0.091
-assembly: 0.086
-permissions: 0.086
-hypervisor: 0.079
-virtual: 0.053
-kernel: 0.038
-performance: 0.037
-architecture: 0.027
-graphic: 0.014
-socket: 0.014
-KVM: 0.010
-user-level: 0.008
-mistranslation: 0.007
-vnc: 0.007
-peripherals: 0.005
-network: 0.004
-x86: 0.003
-risc-v: 0.002
-i386: 0.000
-arm: 0.000
-
-hw/ppc: Aborted (core dumped)
-
-Reproducable:
-$ ./ppc64-softmmu/qemu-system-ppc64 -S -machine ppce500,accel=tcg -device spapr-pci-host-bridge
-
-
-qemu/hw/ppc/spapr_pci.c:1567:spapr_phb_realize: Object 0x55bda99744a0 is not an instance of type spapr-machine
-Aborted (core dumped)
-
-This is addressed by commit:
-
-"f7d6bfc spapr_pci: fail gracefully with non-pseries machine types"
-
-
-$ ./v2.11.0-1421-g7d84845/bin/qemu-system-ppc64 -S -machine ppce500,accel=tcg -device spapr-pci-host-bridge
-qemu-system-ppc64: -device spapr-pci-host-bridge: spapr-pci-host-bridge needs a pseries machine
-
-$ git tag --contains f7d6bfc
-v2.11.0
-
-
-1- https://git.qemu.org/?p=qemu.git;a=commit;h=f7d6bfcdc0fe49040aac3ac131a319cb5427957e
-
-As noted in the previous comment, this bug was fixed in the 2.11 release.
-
-
diff --git a/results/classifier/118/semantic-ppc/2378 b/results/classifier/118/semantic-ppc/2378
deleted file mode 100644
index aab30749f..000000000
--- a/results/classifier/118/semantic-ppc/2378
+++ /dev/null
@@ -1,88 +0,0 @@
-semantic: 0.891
-graphic: 0.883
-user-level: 0.841
-ppc: 0.808
-architecture: 0.804
-performance: 0.786
-device: 0.757
-hypervisor: 0.738
-permissions: 0.733
-network: 0.690
-PID: 0.684
-vnc: 0.675
-kernel: 0.645
-peripherals: 0.634
-files: 0.612
-TCG: 0.595
-VMM: 0.585
-x86: 0.581
-mistranslation: 0.581
-register: 0.559
-i386: 0.555
-socket: 0.548
-virtual: 0.512
-KVM: 0.493
-risc-v: 0.487
-assembly: 0.430
-debug: 0.379
-boot: 0.373
-arm: 0.332
---------------------
-user-level: 0.855
-hypervisor: 0.848
-x86: 0.529
-TCG: 0.127
-files: 0.064
-register: 0.023
-debug: 0.019
-PID: 0.013
-i386: 0.013
-kernel: 0.009
-network: 0.007
-VMM: 0.006
-virtual: 0.006
-arm: 0.004
-socket: 0.004
-semantic: 0.004
-device: 0.003
-architecture: 0.003
-assembly: 0.003
-performance: 0.003
-vnc: 0.002
-permissions: 0.001
-boot: 0.001
-peripherals: 0.001
-ppc: 0.001
-graphic: 0.001
-risc-v: 0.001
-KVM: 0.001
-mistranslation: 0.000
-
-make install (meson?) removes needed RPATH for libslirp, making build on CentOS 9 difficult
-Description of problem:
-make install appears to remove need RPATH attributes from the binary, making it difficult if not impossible to install Qemu 9.0.0 on a CentOS 9 machine.
-
-I'm trying to build Qemu 9.0.0 on a CentOS 9 Stream machine where I do not have root.
-The system ships with libslirp-4.4.0-7.el9.src.rpm which is libslirp 4.4.0, which is too old for Qemu.
-
-I checked out https://gitlab.freedesktop.org/slirp/libslirp.git which is 2 commits more recent than
-libslirp 4.8.0.  I installed this version in a separate directory.
-
-When I configure Qemu using PKG_CONFIG_PATH, it builds the correct executable with the correct RPATH.
-readelf -d shows:
-
- 0x000000000000000f (RPATH)              Library rpath: [/web/courses/cs4284/pintostools/lib64]
-
-which is the correct directory where the proper version of libslirp is located.
-
-However, when I run "make install" the RPATH attribute is removed. Thus, Qemu resorts to the system version, which is version 4.4 (with which Qemu won't run.)
-
-Meson's propensity to strip necessary RPATHs appears to be well-known, see, for instance,
-
-https://github.com/mesonbuild/meson/issues/4027
-
-(There is a fix for at least some of the problems in 0.55.0 of Meson
-https://mesonbuild.com/Release-notes-for-0-55-0.html
-Qemu 9.0.0 appears to use Meson 1.2.3., but yet it still fails.)
-
-Work-around: don't use make install, copy it directly from the build directory to the destination directory.
diff --git a/results/classifier/118/semantic-ppc/833658 b/results/classifier/118/semantic-ppc/833658
deleted file mode 100644
index d5c5d5843..000000000
--- a/results/classifier/118/semantic-ppc/833658
+++ /dev/null
@@ -1,83 +0,0 @@
-ppc: 0.910
-graphic: 0.841
-semantic: 0.821
-architecture: 0.816
-kernel: 0.809
-performance: 0.785
-user-level: 0.778
-virtual: 0.768
-peripherals: 0.763
-register: 0.744
-device: 0.740
-hypervisor: 0.692
-PID: 0.680
-files: 0.667
-boot: 0.659
-permissions: 0.629
-socket: 0.624
-x86: 0.621
-network: 0.609
-mistranslation: 0.578
-debug: 0.578
-VMM: 0.567
-vnc: 0.553
-arm: 0.542
-i386: 0.533
-KVM: 0.512
-TCG: 0.491
-risc-v: 0.472
-assembly: 0.450
---------------------
-virtual: 0.982
-ppc: 0.974
-user-level: 0.879
-debug: 0.111
-boot: 0.095
-network: 0.057
-files: 0.047
-kernel: 0.027
-hypervisor: 0.023
-socket: 0.015
-register: 0.012
-PID: 0.010
-performance: 0.006
-device: 0.005
-semantic: 0.004
-vnc: 0.004
-graphic: 0.003
-peripherals: 0.003
-VMM: 0.003
-architecture: 0.003
-TCG: 0.002
-assembly: 0.001
-permissions: 0.001
-risc-v: 0.001
-x86: 0.001
-KVM: 0.001
-mistranslation: 0.000
-arm: 0.000
-i386: 0.000
-
-Qemu ppc does not boot Debian 3.1r8
-
-I tried booting the official image debian-31r8-powerpc-binary-1.iso with the following commandline:
-qemu-system-ppc -boot d -cdrom ../debian-31r8-powerpc-binary-1.iso -hda hd.img. The booting process stops with CPU at 100%. I can choose to boot "install-2.4" or "install" which both hangs with the last output being "Loading ramdisk". I have also tried using the git-tree which crashes qemu with the message "qemu/memory.c:1183: memory_region_add_subregion_common: Assertion `!subregion->parent' failed." before even showing anything.
-
-Additionally, qemu 0.14.1 shows the same behaviour but qemu 0.13 and 0.12.5 can boot beyond the "Loading ramdisk" message but stops immediatly afterwards with a messed up console window (letters are pushed into another, which makes them barely readable) when using "install". Also "install-2.4" boots with 0.13 and 0.12.5 beyond the "Loading ramdisk" message but stops with the last message being now "returning 0x01400000 from prom_init".
-
-Hi,
-
-this might be related to this upstream bug report: http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02929.html.
-
-Since it seems to be an issue with the mapping of the video memory, I have tried changing the graphics adapter. After changing it from "vga" to "cirrus", the virtual machine in my case would boot again.
-
-Adrian
-
-I just accidentially came across this bug report ... I did not find debian-31r8-powerpc-binary-1.iso anymore in the internet, but debian-31r8-powerpc-netinst.iso is still available, so I gave it a try: There is no output of grub in the VGA window with this ISO, but if I simply press return when the screen turns black, the kernel seems to boot and work fine with the latest version of QEMU (2.6.0). So I think this problem has likely been fixed and we can close this bug now.
-
-Just to add here: from my local tests with other older images, the text is there on the black screen but just extremely faint. My guess is that it's an endian-related bug in OpenBIOS programming the VGA registers but haven't had much time to dig into it.
-
-
-FWIW the text becomes visible again if you switch QEMU to 8-bit mode rather than 32-bit mode, e.g. adding -g 800x600x8 to the command line.
-
-