restructure results

9 files changed, 0 insertions, 655 deletions

diff --git a/results/classifier/118/PID/1426 b/results/classifier/118/PID/1426
deleted file mode 100644
index 37b4174a..00000000
--- a/results/classifier/118/PID/1426
+++ /dev/null
@@ -1,68 +0,0 @@
-PID: 0.864
-device: 0.832
-socket: 0.829
-register: 0.828
-ppc: 0.756
-arm: 0.725
-risc-v: 0.724
-VMM: 0.716
-files: 0.699
-mistranslation: 0.689
-performance: 0.672
-vnc: 0.671
-graphic: 0.668
-network: 0.648
-boot: 0.643
-architecture: 0.626
-hypervisor: 0.616
-semantic: 0.609
-user-level: 0.602
-KVM: 0.552
-permissions: 0.533
-x86: 0.525
-debug: 0.480
-TCG: 0.432
-peripherals: 0.413
-kernel: 0.374
-virtual: 0.334
-i386: 0.321
-assembly: 0.256
-
-On windows, display spice-app is not able to initialize, start spice-server and consequently can't use spice-client
-Description of problem:
-I want to try windows spice-client / virt-viewer.exe (v11.0.256) instead of gtk client.  
-Windows spice client virtviewer won't start like it does under Linux.  
-The error message indicaes that the spice-server itself failed to open spice sockets
-The registry to handle ```spice://``` URI handler is configured.
-Steps to reproduce:
-1. just run command
-Additional information:
-URI handler in registry is configure using a regestry import file ```spiceproto.reg```
-```
-Windows Registry Editor Version 5.00
-
-[HKEY_CLASSES_ROOT\spice]
-"URL Protocol"=""
-
-[HKEY_CLASSES_ROOT\spice\DefaultIcon]
-@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
-
-[HKEY_CLASSES_ROOT\spice\Extensions]
-[HKEY_CLASSES_ROOT\spice\shell]
-[HKEY_CLASSES_ROOT\spice\shell\open]
-[HKEY_CLASSES_ROOT\spice\shell\open\command] 
-@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
-
-[HKEY_CLASSES_ROOT\spice+unix]
-"URL Protocol"=""
-
-[HKEY_CLASSES_ROOT\spice+unix\DefaultIcon]
-@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
-
-[HKEY_CLASSES_ROOT\spice+unix\Extensions]
-[HKEY_CLASSES_ROOT\spice+unix\shell]
-[HKEY_CLASSES_ROOT\spice+unix\shell\open]
-[HKEY_CLASSES_ROOT\spice+unix\shell\open\command] 
-@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
-```
-This URI handler is working, and can be seen to work by typing ```spice://abcdefg``` in firefox.
diff --git a/results/classifier/118/PID/1705 b/results/classifier/118/PID/1705
deleted file mode 100644
index cd35fa0a..00000000
--- a/results/classifier/118/PID/1705
+++ /dev/null
@@ -1,96 +0,0 @@
-PID: 0.865
-user-level: 0.843
-debug: 0.831
-graphic: 0.829
-hypervisor: 0.804
-permissions: 0.803
-vnc: 0.789
-mistranslation: 0.788
-semantic: 0.785
-risc-v: 0.784
-device: 0.781
-performance: 0.778
-x86: 0.770
-peripherals: 0.767
-virtual: 0.766
-architecture: 0.762
-arm: 0.761
-boot: 0.745
-TCG: 0.744
-files: 0.729
-assembly: 0.728
-register: 0.726
-network: 0.725
-kernel: 0.715
-VMM: 0.709
-KVM: 0.699
-ppc: 0.697
-socket: 0.679
-i386: 0.633
-
-Illegal instruction when I want to numactl --cpubind=0 --membind=1 to CXL Memory
-Description of problem:
-I ran QEMU for simulating CXL DRAM and when I tried to run `numactl --cpubind=0 --membind=1  ls` , I got `Illegal instruction`
-The numa node 1 was the CXL DRAM simulated by QEMU.
-
-> root@8003:~# numactl -H
-> available: 2 nodes (0-1)
-> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
-> node 0 size: 32090 MB
-> node 0 free: 31325 MB
-> node 1 cpus:
-> node 1 size: 32768 MB
-> node 1 free: 32768 MB
-> node distances:
-> node 0 1
-> 0: 10 20
-> 1: 20 10
-
-When I ran on numa node 1, no failed
-
-> root@8003:~# numactl --membind=0 ls
-> ndctl
-
-When I ran on numa node 1(CXL DRAM),it failed.
-
-> root@8003:~# numactl --membind=1 ls
-> [ 913.975032] traps: ls[667] trap invalid opcode ip:7fdec255d180 sp:7ffd3c507288 error:0 in ld-linux-x86-64.so.2[7fdec2546000+2a000]
-> **Illegal instruction**
-Steps to reproduce:
-1. start the guest
-2. cxl list  (we could see the simulated CXL DRAM)
-> root@8003:~# cxl list
-> [
->   {
->     "memdev":"mem0",
->     "ram_size":34359738368,
->     "serial":0,
->     "host":"0000:0d:00.0"
->   }
-> ]
-3. cxl create-region -t ram -d decoder0.0 -m mem0
-4. daxctl reconfigure-device dax0.0 --mode=system-ram
-5. numactl -H
-> root@8003:~# numactl -H
-> available: 2 nodes (0-1)
-> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
-> node 0 size: 32090 MB
-> node 0 fr
-> ee: 31254 MB
-> node 1 cpus:
-> node 1 size: 32768 MB
-> node 1 free: 32768 MB
-> node distances:
-> node   0   1 
->   0:  10  20 
->   1:  20  10 
-6. numactl --membind=1 ls
-> root@8003:~# numactl --membind=1 ls
-> [38441.892140] **traps: ls[861] trap invalid opcode ip:7f15db6ac180 sp:7ffc648755c8 **error:0 in ld-linux-x86-64.so.2[7f15db695000+2a000]
-> **Illegal instruction**
-Additional information:
-When I run dmesg, I found an error.
-> root@8003:~# dmesg|grep error
-> [    2.321130] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
-
-Since my CPU is a Xeon III, not a Xeon IV with CXL support, **I'm wondering if it's because the CPU doesn't support CXL instructions, or if the Xeon III can emulate it, just because my settings don't make sense**. If this is my settings problem, could you help me to deal this? Or it just caused by my Xeon III,I will update it to  Xeon IV.
diff --git a/results/classifier/118/PID/1721 b/results/classifier/118/PID/1721
deleted file mode 100644
index b0bb9d30..00000000
--- a/results/classifier/118/PID/1721
+++ /dev/null
@@ -1,92 +0,0 @@
-PID: 0.870
-permissions: 0.860
-assembly: 0.858
-graphic: 0.852
-semantic: 0.838
-device: 0.833
-architecture: 0.830
-register: 0.827
-files: 0.826
-socket: 0.826
-arm: 0.824
-KVM: 0.822
-virtual: 0.820
-TCG: 0.819
-VMM: 0.811
-peripherals: 0.811
-user-level: 0.807
-vnc: 0.797
-ppc: 0.793
-debug: 0.788
-kernel: 0.778
-hypervisor: 0.768
-x86: 0.743
-performance: 0.730
-risc-v: 0.721
-boot: 0.720
-i386: 0.672
-network: 0.645
-mistranslation: 0.595
-
-Problem in combination with RabbitMQ and erlang
-Description of problem:
-I have a problem with rabbitMQ /erlang / Qemu on my local system.
-
-I use docker with:
-
-version: "3.6"
-```
-services:
-  rabbitmq:
-    image: rabbitmq:3-management
-```
-
-Docker Desktop 4.20.1 (110738) 
-Docker version 24.0.2, build cb74dfc
-
-Apple Macbook Pro with M1 Chip Ventura 13.4.
-
-I deleted all containers and images related to rabbitMQ. Then when I do a: docker compose up -d
-
-I always get this error and rabbitMQ stopps:
-
-```
-rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:18.984151+00:00 [notice] <0.44.0> Application mnesia exited with reason: stopped
-rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:20.658039+00:00 [info] <0.230.0> Waiting for Mnesia tables for 30000 ms, 9 retries left
-rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:20.659274+00:00 [info] <0.230.0> Successfully synced tables from a peer
-rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:20.662647+00:00 [notice] <0.283.0> Feature flags: attempt to enable `stream_sac_coordinator_unblock_group`...
-rabbitmq-server-rabbitmq-1  | 2023-06-22 08:12:20.793670+00:00 [notice] <0.283.0> Feature flags: `stream_sac_coordinator_unblock_group` enabled
-rabbitmq-server-rabbitmq-1  | qemu: uncaught target signal 11 (Segmentation fault) - core dumped
-rabbitmq-server-rabbitmq-1  | Segmentation fault
-```
-
-In the past it worked, like 5 months ago.
-
-Reproduction steps docker compose up -d
-
-Expected behavior that the container runs and does not exit
-
-Additional context docker compose logs
-
-```
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.946635+00:00 [notice] <0.44.0> Application syslog exited with reason: stopped
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.966134+00:00 [notice] <0.230.0> Logging: switching to configured handler(s); following messages may not be visible in this log output
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.973002+00:00 [notice] <0.230.0> Logging: configured log handlers are now ACTIVE
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539052+00:00 [info] <0.230.0> ra: starting system quorum_queues
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539748+00:00 [info] <0.230.0> starting Ra system: quorum_queues in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/quorum/rabbit@4fb71bcd203a
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.715984+00:00 [info] <0.261.0> ra system 'quorum_queues' running pre init for 0 registered servers
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.749375+00:00 [info] <0.262.0> ra: meta data store initialised for system quorum_queues. 0 record(s) recovered
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.786151+00:00 [notice] <0.267.0> WAL: ra_log_wal init, open tbls: ra_log_open_mem_tables, closed tbls: ra_log_closed_mem_tables
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857344+00:00 [info] <0.230.0> ra: starting system coordination
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857635+00:00 [info] <0.230.0> starting Ra system: coordination in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/coordination/rabbit@4fb71bcd203a
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.868808+00:00 [info] <0.274.0> ra system 'coordination' running pre init for 0 registered servers
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.874965+00:00 [info] <0.275.0> ra: meta data store initialised for system coordination. 0 record(s) recovered
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.875747+00:00 [notice] <0.280.0> WAL: ra_coordination_log_wal init, open tbls: ra_coordination_log_open_mem_tables, closed tbls: ra_coordination_log_closed_mem_tables
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0>
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Starting RabbitMQ 3.12.0 on Erlang 25.3.2.2 [jit]
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Copyright (c) 2007-2023 VMware, Inc. or its affiliates.
-rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Licensed under the MPL 2.0. Website: https://rabbitmq.com
-rabbitmq-server-rabbitmq-1 |
-rabbitmq-server-rabbitmq-1 |
-Additional information:
-
diff --git a/results/classifier/118/PID/1760 b/results/classifier/118/PID/1760
deleted file mode 100644
index 4e4b3050..00000000
--- a/results/classifier/118/PID/1760
+++ /dev/null
@@ -1,83 +0,0 @@
-i386: 0.991
-PID: 0.966
-kernel: 0.957
-architecture: 0.944
-performance: 0.934
-graphic: 0.920
-device: 0.909
-files: 0.860
-debug: 0.831
-ppc: 0.775
-peripherals: 0.771
-network: 0.727
-permissions: 0.714
-user-level: 0.659
-assembly: 0.651
-arm: 0.622
-VMM: 0.616
-vnc: 0.615
-socket: 0.609
-TCG: 0.596
-boot: 0.551
-KVM: 0.516
-semantic: 0.502
-hypervisor: 0.476
-register: 0.449
-risc-v: 0.445
-mistranslation: 0.426
-x86: 0.321
-virtual: 0.169
-
-qemu8-i386 gets wrong arguments for 32-bit old mmap syscall (_NR_mmap = 90)
-Description of problem:
-qemu8-i386 does not decode syscall arguments correctly for system call _NR_mmap = 90 on i386.
-```
-$ strace ./oldmmap
-execve("./oldmmap", ["./oldmmap"], 0x7fff46ba6d40 /* 61 vars */) = 0
-[ Process PID=405233 runs in 32 bit mode. ]
-mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fa7000
-exit(5)                                 = ?
-+++ exited with 5 +++
-
-$ build/qemu-i386 -strace ./oldmmap
-405254 mmap(0x40800058,0,PROT_NONE,0,0,0) = 0x3fffb000
-405254 exit(5)
-```
-Steps to reproduce:
-1. gcc -m32 -o oldmmap -nostartfiles -nostdlib oldmmap.S  # build 32-bit executable
-2. strace ./oldmmap  # run under strace
-3. build/qemu-i386 -strace ./oldmmap  # run under "qemu-i386 -strace"
-4. Notice that qemu-i386 did not report the same arguments to the _NR_map syscall as /usr/bin/strace did.
-Additional information:
-```
-$ cat oldmmap.S
-MAP_FIXED=     0x10
-MAP_PRIVATE=   0x02
-MAP_ANONYMOUS= 0x20
-
-PROT_READ=      1
-PROT_WRITE=     2
-PROT_EXEC=      4
-
-_NR_exit = 1
-_NR_mmap = 90  // oldmmap: %ebx -> array of 6 arguments
-
-    .globl _start
-_start:
-    push $0  // offset
-    push $-1  // fd
-    push $MAP_PRIVATE|MAP_ANONYMOUS  // flags
-    push $PROT_READ|PROT_WRITE  // protection
-    push $2<<12  // length
-    push $0  // addr (kernel chooses)
-    mov %esp,%ebx
-    mov $_NR_mmap,%eax
-    int $0x80
-    nop
-
-    mov $5,%ebx
-    mov $_NR_exit,%eax
-    int $0x80
-    hlt
-$ 
-```
diff --git a/results/classifier/118/PID/1821054 b/results/classifier/118/PID/1821054
deleted file mode 100644
index 4abcd9d4..00000000
--- a/results/classifier/118/PID/1821054
+++ /dev/null
@@ -1,83 +0,0 @@
-PID: 0.959
-user-level: 0.958
-semantic: 0.914
-mistranslation: 0.913
-ppc: 0.913
-graphic: 0.909
-architecture: 0.906
-device: 0.904
-performance: 0.894
-peripherals: 0.885
-permissions: 0.885
-TCG: 0.868
-risc-v: 0.867
-i386: 0.858
-debug: 0.844
-assembly: 0.830
-register: 0.825
-x86: 0.818
-vnc: 0.818
-hypervisor: 0.805
-VMM: 0.804
-socket: 0.761
-kernel: 0.750
-KVM: 0.722
-arm: 0.708
-boot: 0.699
-network: 0.697
-files: 0.693
-virtual: 0.620
-
-qemu segfault error when using pcie to dual pci adapter
-
-All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor"
-I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum.
-
-hmm that's a fun board.
-
-It looks like qemu has segfaulted;
-   1) is this a qemu build you built yourself? If so, exactly which version, built on which distro?
-   2) Could you get a backtrace of qemu crashing  - this might be easiest if your distro records core dumps somewhere.
-
-FYI: I was happy to find the board and I'm hopeful to get it working. My goal is to use old hardware to make a retro gaming machine for my girls to play games I used to play growing up.
-
-1)No its the qemu installed with unraid version 6.6.7, which i believe is qemu 3.0
-2)im willing to get any notes, logs, or dumps you wish. I just need to know how to do it.
-
-I don't know anything about unraid unfortunately; so I suggest you go back to their forums and ask how to get the backtrace.
-
-I have requested additional info in the other forum. While I wait on reply there, i will say, since you dont know it well, that Unraid is a disto built on top of slackware. Are there any basic command line commands that i could run to get the output you requested, or something to keep things moving while i wait on additional info from the other forum.
-
-Hi! Did you ever get a backtrace? ... otherwise I think we have to close this ticket due to insufficient data...
-
-No I never did. I reached out to try and get info on how to run or get a backtrack and never heard anything. I finally gave up and ended up selling the computer since I never got it working how I wanted to. 
-
-> On Nov 25, 2020, at 10:20 AM, Thomas Huth <email address hidden> wrote:
-> 
-> Hi! Did you ever get a backtrace? ... otherwise I think we have to close
-> this ticket due to insufficient data...
-> 
-> ** Changed in: qemu
->       Status: New => Incomplete
-> 
-> -- 
-> You received this bug notification because you are subscribed to the bug
-> report.
-> https://bugs.launchpad.net/bugs/1821054
-> 
-> Title:
->  qemu segfault error when using pcie to dual pci adapter
-> 
-> Status in QEMU:
->  Incomplete
-> 
-> Bug description:
->  All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor"
->  I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum.
-> 
-> To manage notifications about this bug go to:
-> https://bugs.launchpad.net/qemu/+bug/1821054/+subscriptions
-
-
-Ok, thanks for getting back. So I'm closing this now due to insufficient data.
-
diff --git a/results/classifier/118/PID/1825452 b/results/classifier/118/PID/1825452
deleted file mode 100644
index 71e26b0a..00000000
--- a/results/classifier/118/PID/1825452
+++ /dev/null
@@ -1,76 +0,0 @@
-ppc: 0.945
-user-level: 0.931
-PID: 0.921
-permissions: 0.915
-network: 0.865
-files: 0.856
-register: 0.849
-debug: 0.845
-mistranslation: 0.831
-vnc: 0.825
-semantic: 0.816
-device: 0.815
-graphic: 0.809
-architecture: 0.788
-virtual: 0.751
-kernel: 0.738
-peripherals: 0.737
-performance: 0.735
-socket: 0.732
-arm: 0.716
-boot: 0.684
-risc-v: 0.651
-VMM: 0.645
-assembly: 0.636
-TCG: 0.584
-x86: 0.515
-hypervisor: 0.514
-i386: 0.439
-KVM: 0.377
-
-Pulse audio backend doesn't work in  v4.0.0-rc4 release
-
-Using Gentoo linux, build from source: qemu v4.0.0-rc4 release (eeba63fc7fface36f438bcbc0d3b02e7dcb59983)
-
-Pulse audio backend doesn't initialize because of the:
-audio/paaudio.c:
--    if (!popts->has_server) {
--        char pidfile[64];
--        char *runtime;
--        struct stat st;
--
--        runtime = getenv("XDG_RUNTIME_DIR");
--        if (!runtime) {
--            return NULL;
--        }
--        snprintf(pidfile, sizeof(pidfile), "%s/pulse/pid", runtime);
--        if (stat(pidfile, &st) != 0) {
--            return NULL;
--        }
--    }
-XDG_RUNTIME_DIR is not set for me. There is no /run/user directory exist in my system.
-
-Also:
-$ less ~/.pulse/client.conf  
-default-server = unix:/home/ivan/.pulse_server
-
-Removing this lines makes pa backend work fine again. Much better than 3.x versions due to buffer fixes.
-
-It looks like this code relies on the systemd specifics and doesn't work with OpenRC used in Gentoo by default. Still not fixed in 4.0.0 release.
-
-You can use -audiodev pa,id=whatever,server=unix:/home/ivan/.pulse_server to get things going with your configuration.
-
-Oh, and this has nothing to do with systemd:
-
-kraxel@gentoo ~ $ set | grep ^XDG
-XDG_CONFIG_DIRS=/etc/xdg
-XDG_DATA_DIRS=/usr/local/share:/usr/share
-XDG_RUNTIME_DIR=/var/run/user/1000
-XDG_SESSION_COOKIE=gentoo-1556780854.41316-799155214
-
-(gentoo with openrc + xfce, serial console login, x11 login has a few more of these set).
-
-Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/PID/2423 b/results/classifier/118/PID/2423
deleted file mode 100644
index 58dd1f98..00000000
--- a/results/classifier/118/PID/2423
+++ /dev/null
@@ -1,64 +0,0 @@
-PID: 0.960
-x86: 0.905
-performance: 0.877
-graphic: 0.868
-device: 0.779
-peripherals: 0.749
-permissions: 0.701
-semantic: 0.674
-debug: 0.645
-user-level: 0.611
-kernel: 0.562
-register: 0.560
-architecture: 0.553
-vnc: 0.508
-ppc: 0.508
-socket: 0.498
-network: 0.492
-boot: 0.448
-risc-v: 0.420
-i386: 0.418
-mistranslation: 0.400
-files: 0.386
-TCG: 0.372
-VMM: 0.362
-arm: 0.324
-KVM: 0.264
-hypervisor: 0.233
-virtual: 0.171
-assembly: 0.145
-
-`qemu -serial stdio` leaves stdout in non-blocking mode
-Description of problem:
-When `-serial stdio` is used, qemu exits leaving stdout in non-blocking mode. Although it [attempts](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L52) to restore stdin to blocking mode, it misses that stdout also gets O_NONBLOCK by [qemu_chr_open_fd](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L116) ([here](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-fd.c#L215)). It causes the next applications in the script misbehave because they get unexpected EAGAIN on write to stdout.
-Steps to reproduce:
-Run the following script:
-
-```
-#!/usr/bin/env bash
-
-qemu-system-x86_64 -nodefaults -display none -no-reboot -serial stdio &
-PID="$!"
-sleep 5
-kill "$PID"
-wait "$PID"
-echo "EXITING $?"
-
-sleep 5
-seq 1 400000
-```
-
-The seq command will be interrupted prematurely:
-
-```
-...
-5143
-5144
-5145⏎                                                                                                                                                                                                                wResource temporarily unavailable
-write: Resource temporarily unavailable
-write: Resource temporarily unavailable
-```
-
-When run from fish shell, it will also start misbehaving when running next commands (fish bug report: https://github.com/fish-shell/fish-shell/issues/10600).
-Additional information:
-Expect a patch from me soon.
diff --git a/results/classifier/118/PID/303 b/results/classifier/118/PID/303
deleted file mode 100644
index 68bb0405..00000000
--- a/results/classifier/118/PID/303
+++ /dev/null
@@ -1,31 +0,0 @@
-PID: 0.869
-device: 0.847
-performance: 0.623
-mistranslation: 0.507
-architecture: 0.464
-debug: 0.408
-graphic: 0.352
-semantic: 0.350
-x86: 0.270
-boot: 0.268
-i386: 0.239
-arm: 0.212
-register: 0.181
-TCG: 0.180
-ppc: 0.123
-assembly: 0.113
-virtual: 0.103
-VMM: 0.101
-files: 0.098
-peripherals: 0.092
-vnc: 0.089
-network: 0.087
-user-level: 0.084
-socket: 0.079
-risc-v: 0.065
-permissions: 0.051
-kernel: 0.014
-KVM: 0.006
-hypervisor: 0.005
-
-assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed
diff --git a/results/classifier/118/PID/655 b/results/classifier/118/PID/655
deleted file mode 100644
index 51b05e55..00000000
--- a/results/classifier/118/PID/655
+++ /dev/null
@@ -1,62 +0,0 @@
-PID: 0.989
-kernel: 0.972
-ppc: 0.969
-device: 0.968
-architecture: 0.963
-files: 0.948
-graphic: 0.942
-semantic: 0.936
-permissions: 0.892
-vnc: 0.884
-VMM: 0.878
-TCG: 0.871
-performance: 0.868
-network: 0.853
-socket: 0.852
-register: 0.848
-debug: 0.832
-KVM: 0.828
-risc-v: 0.811
-hypervisor: 0.781
-boot: 0.745
-virtual: 0.738
-user-level: 0.735
-arm: 0.716
-mistranslation: 0.637
-peripherals: 0.629
-x86: 0.343
-assembly: 0.261
-i386: 0.079
-
-Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8'
-Description of problem:
-The `java` command fails with the following message:
-
-```console
-$ /usr/lib/jvm/java-17-openjdk-s390x/bin/java --version
-#
-# A fatal error has been detected by the Java Runtime Environment:
-#
-# SIGILL (0x4) at pc=0x000003ff9e4fe6f4, pid=2883, tid=2884
-#
-# JRE version: (17.0+35) (build )
-# Java VM: OpenJDK 64-Bit Server VM (17+35-Ubuntu-120.04, mixed
-# mode, sharing, tiered, compressed oops, compressed class ptrs,
-# serial gc, linux-s390x)
-# Problematic frame:
-# C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8
-#
-# Core dump will be written. Default location: Core dumps may
-# be processed with "/usr/share/apport/apport %p %s %c %d %P %E"
-# (or dumping to /home/ubuntu/core.2883)
-#
-# An error report file with more information is saved as:
-# /home/ubuntu/hs_err_pid2883.log
-#
-#
-Aborted (core dumped)
-```
-Steps to reproduce:
-1. Run `java --version`
-Additional information:
-The corresponding log file is attached as the file [hs_err_pid2883.log](/uploads/1631b6a0f0aad2f77c4928ed6bb540c6/hs_err_pid2883.log).