From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Thu, 3 Jul 2025 19:39:53 +0200
Subject: restructure results

---
 results/classifier/118/boot/1026176 |  56 ----------------
 results/classifier/118/boot/1055090 |  56 ----------------
 results/classifier/118/boot/1101    |  42 ------------
 results/classifier/118/boot/1131    |  50 --------------
 results/classifier/118/boot/1221797 |  73 ---------------------
 results/classifier/118/boot/1256548 |  46 -------------
 results/classifier/118/boot/1273944 |  90 --------------------------
 results/classifier/118/boot/1285508 |  70 --------------------
 results/classifier/118/boot/1290370 |  71 --------------------
 results/classifier/118/boot/1348    |  31 ---------
 results/classifier/118/boot/1516    |  69 --------------------
 results/classifier/118/boot/1589    |  40 ------------
 results/classifier/118/boot/1589153 |  79 ----------------------
 results/classifier/118/boot/1605045 |  46 -------------
 results/classifier/118/boot/1638    |  49 --------------
 results/classifier/118/boot/1652286 |  68 -------------------
 results/classifier/118/boot/1745    |  97 ---------------------------
 results/classifier/118/boot/1826    |  59 -----------------
 results/classifier/118/boot/1840920 |  44 -------------
 results/classifier/118/boot/1859106 |  82 -----------------------
 results/classifier/118/boot/1873338 | 101 -----------------------------
 results/classifier/118/boot/1879590 | 103 -----------------------------
 results/classifier/118/boot/1906181 |  76 ----------------------
 results/classifier/118/boot/2034    |  38 -----------
 results/classifier/118/boot/2212    |  47 --------------
 results/classifier/118/boot/2360    |  60 -----------------
 results/classifier/118/boot/2400    |  73 ---------------------
 results/classifier/118/boot/2620    |  39 -----------
 results/classifier/118/boot/2699    |  48 --------------
 results/classifier/118/boot/2754    |  56 ----------------
 results/classifier/118/boot/2782    |  40 ------------
 results/classifier/118/boot/2810    |  31 ---------
 results/classifier/118/boot/2863    |  31 ---------
 results/classifier/118/boot/2957    |  58 -----------------
 results/classifier/118/boot/2959    | 107 ------------------------------
 results/classifier/118/boot/436     |  31 ---------
 results/classifier/118/boot/475     |  31 ---------
 results/classifier/118/boot/499     |  31 ---------
 results/classifier/118/boot/622     |  31 ---------
 results/classifier/118/boot/721825  | 126 ------------------------------------
 results/classifier/118/boot/797     |  39 -----------
 results/classifier/118/boot/822408  | 100 ----------------------------
 results/classifier/118/boot/87      |  31 ---------
 results/classifier/118/boot/886     |  46 -------------
 results/classifier/118/boot/907     |  37 -----------
 results/classifier/118/boot/997     |  47 --------------
 46 files changed, 2676 deletions(-)
 delete mode 100644 results/classifier/118/boot/1026176
 delete mode 100644 results/classifier/118/boot/1055090
 delete mode 100644 results/classifier/118/boot/1101
 delete mode 100644 results/classifier/118/boot/1131
 delete mode 100644 results/classifier/118/boot/1221797
 delete mode 100644 results/classifier/118/boot/1256548
 delete mode 100644 results/classifier/118/boot/1273944
 delete mode 100644 results/classifier/118/boot/1285508
 delete mode 100644 results/classifier/118/boot/1290370
 delete mode 100644 results/classifier/118/boot/1348
 delete mode 100644 results/classifier/118/boot/1516
 delete mode 100644 results/classifier/118/boot/1589
 delete mode 100644 results/classifier/118/boot/1589153
 delete mode 100644 results/classifier/118/boot/1605045
 delete mode 100644 results/classifier/118/boot/1638
 delete mode 100644 results/classifier/118/boot/1652286
 delete mode 100644 results/classifier/118/boot/1745
 delete mode 100644 results/classifier/118/boot/1826
 delete mode 100644 results/classifier/118/boot/1840920
 delete mode 100644 results/classifier/118/boot/1859106
 delete mode 100644 results/classifier/118/boot/1873338
 delete mode 100644 results/classifier/118/boot/1879590
 delete mode 100644 results/classifier/118/boot/1906181
 delete mode 100644 results/classifier/118/boot/2034
 delete mode 100644 results/classifier/118/boot/2212
 delete mode 100644 results/classifier/118/boot/2360
 delete mode 100644 results/classifier/118/boot/2400
 delete mode 100644 results/classifier/118/boot/2620
 delete mode 100644 results/classifier/118/boot/2699
 delete mode 100644 results/classifier/118/boot/2754
 delete mode 100644 results/classifier/118/boot/2782
 delete mode 100644 results/classifier/118/boot/2810
 delete mode 100644 results/classifier/118/boot/2863
 delete mode 100644 results/classifier/118/boot/2957
 delete mode 100644 results/classifier/118/boot/2959
 delete mode 100644 results/classifier/118/boot/436
 delete mode 100644 results/classifier/118/boot/475
 delete mode 100644 results/classifier/118/boot/499
 delete mode 100644 results/classifier/118/boot/622
 delete mode 100644 results/classifier/118/boot/721825
 delete mode 100644 results/classifier/118/boot/797
 delete mode 100644 results/classifier/118/boot/822408
 delete mode 100644 results/classifier/118/boot/87
 delete mode 100644 results/classifier/118/boot/886
 delete mode 100644 results/classifier/118/boot/907
 delete mode 100644 results/classifier/118/boot/997

(limited to 'results/classifier/118/boot')

diff --git a/results/classifier/118/boot/1026176 b/results/classifier/118/boot/1026176
deleted file mode 100644
index 25d7c985..00000000
--- a/results/classifier/118/boot/1026176
+++ /dev/null
@@ -1,56 +0,0 @@
-boot: 0.806
-i386: 0.770
-mistranslation: 0.748
-device: 0.746
-kernel: 0.728
-semantic: 0.662
-graphic: 0.636
-performance: 0.624
-user-level: 0.511
-architecture: 0.470
-debug: 0.452
-permissions: 0.425
-register: 0.423
-files: 0.417
-network: 0.395
-x86: 0.387
-ppc: 0.387
-peripherals: 0.379
-assembly: 0.358
-PID: 0.351
-VMM: 0.292
-vnc: 0.275
-socket: 0.262
-TCG: 0.259
-virtual: 0.254
-hypervisor: 0.251
-risc-v: 0.245
-arm: 0.221
-KVM: 0.197
-
-unable to boot squashfs through mtd device
-
-Hi,
-
-I have built latest qemu archive qemu-1.1.1 to be sure of up to date source code.
-I have then built buildroot squashfs image, which can be used correctly with cmdline like:
-
-qemu-system-i386 -m 64 -k fr -boot c -kernel images/bzImage -drive if=ide,file=images/rootfs.squashfs  -append "root=/dev/sda"
-
-Then I wanted to modify cmdline to use real MTD device, like:
-
-qemu-system-i386 -m 64 -k fr -boot c -kernel images/bzImage -drive if=mtd,file=images/rootfs.squashfs  -append "root=/dev/mtdblock0".
-
-But nothing was good under kernel.
-Even if mtd0 is reported through qemu interface (Ctrl Alt+2), no device can be found under kernel even if all drivers are built to use it.
-
-Is this feature okay on qemu-1.1.1 ??
-did I do mistake in my cmdline??
-
-thank you for your help.
-regards,
-
-Triaging old bug tickets... QEMU 1.1 is pretty much outdated, can we close this bug nowadays? Can you still reproduce the issue with the latest version of QEMU?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/boot/1055090 b/results/classifier/118/boot/1055090
deleted file mode 100644
index 15ac282f..00000000
--- a/results/classifier/118/boot/1055090
+++ /dev/null
@@ -1,56 +0,0 @@
-boot: 0.930
-i386: 0.888
-ppc: 0.771
-device: 0.754
-PID: 0.716
-network: 0.672
-register: 0.655
-architecture: 0.625
-performance: 0.602
-socket: 0.585
-TCG: 0.585
-x86: 0.567
-files: 0.564
-semantic: 0.556
-user-level: 0.541
-vnc: 0.541
-debug: 0.527
-hypervisor: 0.516
-graphic: 0.515
-peripherals: 0.436
-permissions: 0.396
-risc-v: 0.383
-kernel: 0.361
-mistranslation: 0.355
-assembly: 0.345
-VMM: 0.296
-arm: 0.284
-virtual: 0.191
-KVM: 0.055
-
-esp error: NetBSD/sparc on qemu-system-sparc 
-
-On qemu-1.2.0's qemu-system-sparc, NetBSD/sparc (32bit) 5.1.2 and 6.0_RC2 generates the following NetBSD's errors.
-
-esp0: !TC on DATA XFER [intr 18, stat 82, step 4] prevphase 2, resid 0
-esp0: !TC on DATA XFER [intr 10, stat 83, step 0] prevphase 2, resid 0
-
-On qemu-0.15.1's qemu-system-sparc, NetBSD/sparc 5.1.2 and 6.0_RC2 works fine.
-
-To reproduce with NetBSD/sparc 6.0_RC2, run
-
-% qemu-system-sparc -M SS-20 -m 265M -hda NetBSD-sparc-6.0_RC2.qed -nographic -cdrom NetBSD-6.0_RC2-sparc.iso -boot d
-
-and try to install NetBSD. You can get above errors when newfs command is invoked.
-I can reporduce this problem on NetBSD/i386 (32bit) and NetBSD/amd64(64bit; x86_64) host OSes.
-
-NetBSD-6.0_RC2-sparc.iso is here,
-ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.0_RC2/images/NetBSD-6.0_RC2-sparc.iso
-
-NetBSD-sparc-6.0_RC2.qed is created with
-% qemu-img create -f qed NetBSD-sparc-6.0_RC2.qed 3G
-
-Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU (and NetBSD)? 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/boot/1101 b/results/classifier/118/boot/1101
deleted file mode 100644
index 69bd1778..00000000
--- a/results/classifier/118/boot/1101
+++ /dev/null
@@ -1,42 +0,0 @@
-boot: 0.918
-device: 0.886
-files: 0.871
-hypervisor: 0.841
-graphic: 0.777
-semantic: 0.724
-performance: 0.711
-architecture: 0.574
-mistranslation: 0.514
-register: 0.485
-socket: 0.477
-permissions: 0.446
-PID: 0.420
-vnc: 0.420
-kernel: 0.399
-network: 0.385
-risc-v: 0.380
-debug: 0.362
-virtual: 0.333
-ppc: 0.314
-arm: 0.290
-assembly: 0.272
-user-level: 0.264
-VMM: 0.252
-TCG: 0.244
-peripherals: 0.244
-x86: 0.230
-i386: 0.220
-KVM: 0.154
-
-QEMU 7.0.0 corrupts VHDX and VHD (VPC) files on write.
-Description of problem:
-QEMU writes to VHDX and VHD (VPC) files produce a corrupt/non-compliant image.
-QEMU appears to be able to read VHDX and VHD images correctly.
-
-This problem manifests in at least two cases
-1. When attaching a VHDX/VHD file to a QEMU machine.  A previously working OS image created using the Hyper-V and imaging tools boots properly, but writes that normally occur in the running VM are not written out correctly.  The image will fail to boot the next time due to corruption.
-2. Image conversion operations *TO* VHDX/VHD fail.  (note that QEMU correctly converts *FROM* VHDX/VHD assuming a well formed input image).  This implies that reads to VHDX/VHD are OK, but writes to VHDX/VHD are NOT OK.
-Steps to reproduce:
-1. See Above.
-Additional information:
-
diff --git a/results/classifier/118/boot/1131 b/results/classifier/118/boot/1131
deleted file mode 100644
index 1db3e27c..00000000
--- a/results/classifier/118/boot/1131
+++ /dev/null
@@ -1,50 +0,0 @@
-boot: 0.842
-device: 0.804
-kernel: 0.736
-graphic: 0.703
-performance: 0.691
-ppc: 0.671
-files: 0.640
-vnc: 0.634
-debug: 0.623
-risc-v: 0.603
-TCG: 0.598
-socket: 0.569
-arm: 0.567
-architecture: 0.552
-i386: 0.542
-VMM: 0.532
-network: 0.531
-x86: 0.518
-semantic: 0.508
-PID: 0.503
-permissions: 0.481
-register: 0.473
-peripherals: 0.452
-user-level: 0.364
-KVM: 0.344
-hypervisor: 0.311
-virtual: 0.301
-mistranslation: 0.250
-assembly: 0.222
-
-Multiboot: could not move values from provided mmap to another address directly.
-Description of problem:
-When using `-kernel` to load a Multiboot file which requires a memory map(MULTIBOOT_MEMORY_INFO flag) and trying to move the values in the provided mmap entries to another address directly, QEMU reboots.
-```c
-xxx = mmap->addr;
-```
-
-When moving with volatile, everything works well:
-```c
-volatile unsigned long long addr = mmap->addr;
-xxx = addr;
-```
-Steps to reproduce:
-1. Source code here: [github/xtexChooser/toop/boot/multiboot/src/multiboot.c](https://github.com/xtexChooser/toop/blob/51153319d4f2320ae9a9277ffffad3f67a335fe9/boot/multiboot/src/multiboot.c#L32)
-2. Minimized reproduce: [gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c](https://gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c)
-3. I am sure that 0x00001210 is writable, it is empty in the memory map and QEMU works correctly when writing a zero value to here.
-4. The reproducer is available without any module, when it works, it should keep running without any output, if QEMU reboots, the screen should flash as it clears and prints the BIOS information again.
-5. If move with volatile(as the `multiboot_works.c` in reproducer), the reproducer works correctly.
-Additional information:
-#
diff --git a/results/classifier/118/boot/1221797 b/results/classifier/118/boot/1221797
deleted file mode 100644
index 8f58ed95..00000000
--- a/results/classifier/118/boot/1221797
+++ /dev/null
@@ -1,73 +0,0 @@
-boot: 0.852
-ppc: 0.839
-user-level: 0.818
-performance: 0.806
-virtual: 0.798
-semantic: 0.744
-KVM: 0.742
-mistranslation: 0.741
-files: 0.738
-device: 0.688
-hypervisor: 0.674
-architecture: 0.671
-register: 0.667
-graphic: 0.639
-vnc: 0.636
-x86: 0.619
-kernel: 0.614
-PID: 0.609
-network: 0.572
-socket: 0.549
-VMM: 0.544
-permissions: 0.472
-risc-v: 0.464
-assembly: 0.432
-i386: 0.412
-debug: 0.392
-peripherals: 0.387
-arm: 0.326
-TCG: 0.323
-
-virt-install gets stuck during downloading install.img
-
-I have tried to install CentOS 6.4 using the latest version of all kvm related tools. My problem is that I get stuck at arround 20% during the download of the file install.img. Everything before that works just fine.
-
-I am using the following commands to install to server:
-virt-install \
-	-n test \
-	-r 1024 \
-	--disk path=/var/kvm/images/test.img,size=25 \
-	--vcpus=1 \
-	--os-type linux \
-	--os-variant=rhel6 \
-	--network bridge=br2 \
-	--nographics \
-	--location='http://mirror.netcologne.de/centos/6.4/os/x86_64' \
-	--extra-args='console=tty0 console=ttyS0,115200n8 serial' \
-
-I have checked that my server is ready for virtualization.
-
-If you need any further information I am happy to provide them
-
-Patrick Gramsl
-
-I guess it could be a problem with the mirror you are using. Have you tried using a different mirror. Following is what I tried and I was able to boot centos
-
-virt-install \
--n test \
--r 1024 \
---disk path=/tmp/test.img,size=3 \
---vcpus=1 \
---os-type linux \
---os-variant=rhel6 \
---network bridge=virbr0 \
---nographics --location='http://centos.mirror.net.in/centos/6.4/os/x86_64' \
---extra-args='console=tty0 console=ttyS0,115200n8 serial'
-
-Sorry yes of course I have tried a different mirror but I think that the problem was with my server installation because even my mail server was not working correctly I will update this comment as soon as I have new information.
-
-@Shivakumar:
-Thank you for your help anyway
-
-This is not a QEMU bug ... for virt-install related problems, please see https://virt-manager.org/bugs/ instead.
-
diff --git a/results/classifier/118/boot/1256548 b/results/classifier/118/boot/1256548
deleted file mode 100644
index 1adf1a95..00000000
--- a/results/classifier/118/boot/1256548
+++ /dev/null
@@ -1,46 +0,0 @@
-boot: 0.868
-device: 0.800
-graphic: 0.648
-network: 0.573
-socket: 0.539
-performance: 0.488
-vnc: 0.487
-architecture: 0.452
-debug: 0.434
-mistranslation: 0.422
-register: 0.418
-semantic: 0.415
-ppc: 0.382
-risc-v: 0.351
-arm: 0.326
-files: 0.281
-PID: 0.236
-VMM: 0.226
-hypervisor: 0.222
-user-level: 0.214
-assembly: 0.192
-permissions: 0.169
-virtual: 0.128
-i386: 0.105
-peripherals: 0.093
-TCG: 0.093
-x86: 0.050
-kernel: 0.032
-KVM: 0.010
-
-qemu windows guest issues
-
-Ive noticed the following in the latest qemu build on mingw 64bit for windows
-
-older guests like windows 9* no longer boot they mostly just bsod its been this way for ages same with 32bit builds
-xp 64bit and other 64bit windows guests no longer work and havent for ages same with 32bit builds 
-xp 32bit guest doesent work under 64bit builds but they work on 32bit builds
-
-are the issues with the coroutine stuff on windows builds being worked on? id gladly test patches
-
-just a few observations is all :)
-
-Which exact version of QEMU did you use? Does this problem still occur with the latest version of QEMU?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/boot/1273944 b/results/classifier/118/boot/1273944
deleted file mode 100644
index 314da771..00000000
--- a/results/classifier/118/boot/1273944
+++ /dev/null
@@ -1,90 +0,0 @@
-boot: 0.935
-graphic: 0.873
-architecture: 0.823
-mistranslation: 0.793
-performance: 0.770
-ppc: 0.769
-device: 0.760
-semantic: 0.745
-kernel: 0.688
-user-level: 0.675
-x86: 0.600
-files: 0.583
-register: 0.579
-hypervisor: 0.578
-network: 0.571
-PID: 0.543
-socket: 0.514
-peripherals: 0.490
-debug: 0.463
-VMM: 0.444
-vnc: 0.409
-i386: 0.407
-TCG: 0.387
-permissions: 0.380
-assembly: 0.372
-risc-v: 0.340
-KVM: 0.334
-arm: 0.294
-virtual: 0.285
-
-multiboot header has 0 in mem_upper field
-
-When booting a multiboot image,. mem_upper is now always zero.
-
-To test, build qemu from current git head, then do
-  cd tests/multiboot
-  ./run_test.sh
-
-You will see the test fail.  In each case mem_upper is 0k.
-
-git-bisect says the bad commit is 0169c511554cb0014a00290b0d3d26c31a49818f in qemu.git
-
-This change fixes it.
-
-diff --git a/exec.c b/exec.c
-index 2435d9e..b387d28 100644
---- a/exec.c
-+++ b/exec.c
-@@ -1070,7 +1070,7 @@ static void *file_ram_alloc(RAMBlock *block,
-         }
- 
-         /* MAP_POPULATE silently ignores failures */
--        for (i = 0; i < (memory/hpagesize); i++) {
-+        for (i = 0; i < (memory/hpagesize)-1; i++) {
-             memset(area + (hpagesize*i), 0, 1);
-         }
- 
-peterc@Diprotodon:/usr/src/qemu/tests/m
-
->>>>> "Peter" == Peter Chubb <email address hidden> writes:
-This change fixes it.
-
-> diff --git a/exec.c b/exec.c
-> index 2435d9e..b387d28 100644
-> --- a/exec.c
-> +++ b/exec.c
-> @@ -1070,7 +1070,7 @@ static void *file_ram_alloc(RAMBlock *block,
->          }
-> 
->          /* MAP_POPULATE silently ignores failures */
-> -        for (i = 0; i < (memory/hpagesize); i++) {
-> +        for (i = 0; i < (memory/hpagesize)-1; i++) {
->              memset(area + (hpagesize*i), 0, 1);
->          }
-
-I don't know why this fixes the issue.  Hence, no signed-off-by line, etc.
-
-My guess is that the memset zeros something it shouldn't off the end of
-the array (but that doesn't make sense to me!)
-
-Peter C
---
-Dr Peter Chubb				        peter.chubb AT nicta.com.au
-http://www.ssrg.nicta.com.au          Software Systems Research Group/NICTA
-
-
-tests/multiboot seems to work with current git again, so I assume this issue has been fixed? Or is there something left to do?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/boot/1285508 b/results/classifier/118/boot/1285508
deleted file mode 100644
index ab3de062..00000000
--- a/results/classifier/118/boot/1285508
+++ /dev/null
@@ -1,70 +0,0 @@
-boot: 0.831
-architecture: 0.831
-device: 0.755
-graphic: 0.707
-mistranslation: 0.700
-semantic: 0.675
-x86: 0.631
-peripherals: 0.612
-performance: 0.608
-user-level: 0.592
-ppc: 0.557
-PID: 0.528
-virtual: 0.499
-permissions: 0.427
-arm: 0.423
-vnc: 0.372
-TCG: 0.347
-network: 0.344
-register: 0.340
-debug: 0.336
-KVM: 0.317
-risc-v: 0.313
-socket: 0.305
-i386: 0.281
-VMM: 0.280
-files: 0.273
-hypervisor: 0.259
-kernel: 0.254
-assembly: 0.093
-
-[ppa 2.0~git-20140225] mouse cursor invisible with Ubuntu live system
-
-As requested on u-devel@, I tested QEMU 2.0~git-20140225.aa0d1f4-0ubuntu2 from ppa:ubuntu-virt/candidate. This has a regression with the mouse cursor.
-
-I downloaded the current Ubuntu Desktop trusty beta-1 amd64 image, and booted it in QEMU:
-
-  $ kvm -m 2048 -cdrom trusty-desktop-amd64.iso
-
-This boots fine, but in the desktop I don't see any mouse cursor.
-
-Interestingly this only happens with sdl.  Using vga it works fine.
-
-It also works fine in qxl/spice (qemu ... -spice disable-ticketing,port=5930;  spicy -h localhost -p 5930).
-
-i have the same, I don't see any mouse cursor. System is working.
-
-Host: Ubuntu release 14.04 x86_64
-Gast: Ubuntu release 14.04 x86_64
-
-Graphic: GeForce GTX 650 Ti BOOST/PCIe/SSE2
-Driver: nvidia 331.38
-
-
-
-there are my terminal commands:
-
-$ qemu-img create -f qcow2 BOOTSYSTEM.img 10G 
-$ qemu-system-x86_64 -enable-kvm -hda BOOTSYSTEM.img -cdrom /dev/cdrom -boot d -m 1024
-
-
-I still regularly get this. The workaround is to open a terminal, which causes the cursor shape to change. Once that is done, the cursor stays visible.
-
-Hi Martin,
-
-when you get this, I assume that is with the standard trusty or utopic package?
-
-I ask because the subject says 'ppa' - i'd like to remove that.
-
-It's actually fine for me with current utopic's 2.1+dfsg-2ubuntu2. I tested both the default graphics card as well as "-vga vmware".
-
diff --git a/results/classifier/118/boot/1290370 b/results/classifier/118/boot/1290370
deleted file mode 100644
index ad5b81c8..00000000
--- a/results/classifier/118/boot/1290370
+++ /dev/null
@@ -1,71 +0,0 @@
-boot: 0.867
-i386: 0.867
-kernel: 0.864
-graphic: 0.863
-PID: 0.839
-virtual: 0.830
-files: 0.807
-user-level: 0.806
-socket: 0.798
-performance: 0.760
-vnc: 0.732
-semantic: 0.724
-network: 0.719
-device: 0.711
-ppc: 0.711
-mistranslation: 0.709
-architecture: 0.661
-x86: 0.650
-register: 0.648
-permissions: 0.607
-TCG: 0.587
-debug: 0.573
-risc-v: 0.571
-VMM: 0.482
-assembly: 0.467
-peripherals: 0.444
-arm: 0.416
-hypervisor: 0.404
-KVM: 0.293
-
-FreeBSD 9.2 shell crashes when run with -smp 4 option
-
-This is a bug that i have noticed in qemu 1.7.50 as well as 1.1.50. It was the latter that forced me to clone the repository to check if this is the case with the resent version as well . The latest commit on which the bug is found is f53f3d0a00b6df39ce8dfca942608e5b6a9a4f71 on qemu.git
-
-configured with target list i386-softmmu
-and then 
-make
- 
-OS: FreeBSD 9.2 Text Install ISO
-Installed it to a qcow2 format image.
-
-./i386-softmmu/qemu-system-i386 -hda <bsd-image> -m 2G -smp 4 -net nic -net user -monitor stdio
-
-(boot into multi-user mode)->(login to root account)
-
-I have the filebench benchmark installed on the image and when i run it the default root shell (csh) crashes with the error.
-[pid xxxx (csh) sigreturn eflag = 0xXXXX]
-Here is the piece of kernel code that is getting executed (i think) http://svnweb.freebsd.org/base/release/9.2.0/sys/i386/i386/machdep.c?view=markup#l1095 
-
-Here is a related bug
-https://www.virtualbox.org/ticket/458
-
-The crash happens randomly. It is not just related with filebench. 
-Here are a few scenarios:
-* When i run fileserver workload of filebench
-* After i issue the shutdown -h now shutdown -r now commands
-* Issuing mount -t linprocfs proc /proc
-
-Moreover it is not guaranteed that the above scenarios will reproduce it (reliably). 
-Basically after running some commands and getting the CPU and the kernel worked up i think.
-
-Hi,
-
-just to be clear, are you saying that commit f53f3d0a00b6df39ce8df fixes the bug, or that that is the latest commit with which you tested?  (since it was Mar 8 :)
-
-I tested on the commit f53f3d0a00b6df39ce8df 
-
-Triaging old bug tickets... can you still reproduce this 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/boot/1348 b/results/classifier/118/boot/1348
deleted file mode 100644
index 2b1b877e..00000000
--- a/results/classifier/118/boot/1348
+++ /dev/null
@@ -1,31 +0,0 @@
-boot: 0.860
-device: 0.790
-performance: 0.750
-network: 0.524
-architecture: 0.466
-graphic: 0.402
-peripherals: 0.313
-debug: 0.287
-vnc: 0.249
-risc-v: 0.211
-register: 0.181
-semantic: 0.157
-permissions: 0.151
-socket: 0.131
-ppc: 0.124
-arm: 0.121
-VMM: 0.119
-user-level: 0.113
-kernel: 0.108
-hypervisor: 0.108
-files: 0.106
-PID: 0.104
-TCG: 0.104
-mistranslation: 0.082
-i386: 0.070
-virtual: 0.067
-x86: 0.049
-assembly: 0.017
-KVM: 0.001
-
-WIN10 MBR/SeaBIOS/CSM machine hangs at boot (same as  #1115  https://gitlab.com/qemu-project/qemu/-/issues/1115 )
diff --git a/results/classifier/118/boot/1516 b/results/classifier/118/boot/1516
deleted file mode 100644
index e53fba88..00000000
--- a/results/classifier/118/boot/1516
+++ /dev/null
@@ -1,69 +0,0 @@
-x86: 0.946
-boot: 0.931
-kernel: 0.928
-architecture: 0.887
-files: 0.881
-device: 0.819
-ppc: 0.799
-graphic: 0.754
-performance: 0.744
-semantic: 0.729
-PID: 0.646
-vnc: 0.610
-permissions: 0.604
-register: 0.591
-i386: 0.557
-risc-v: 0.555
-virtual: 0.526
-arm: 0.518
-VMM: 0.517
-mistranslation: 0.470
-hypervisor: 0.462
-TCG: 0.434
-network: 0.424
-debug: 0.422
-socket: 0.388
-KVM: 0.366
-user-level: 0.317
-assembly: 0.281
-peripherals: 0.200
-
-QEMU does not reload kernel image on guest reboot (direct kernel boot)
-Description of problem:
-I am using virtiofs as root filesystem with QEMU direct kernel boot. The kernel is loaded from the guests directory structure that is exported from the host.
-
-The problem is that QEMU does not reload the kernel image file from disk during a guest reboot. This means it is not possible to update the kernel from inside the guest and do a simple reboot to load it. A full power cycle of the guest is required to load the updated kernel image.
-Steps to reproduce:
-1. Migrate a Linux guest to virtiofs as root fs. 
-2. Enable QEMU direct kernel boot and point to guest's kernel in the exported root filesystem. 
-3. Boot. 
-4. Update the kernel inside the guest. Overwrite the existing kernel image
-5. Issue `reboot` inside the guest. 
-6. When the guest reboots, the old kernel is still booted, even though the image file was overwritten. 
-7. Issue `poweroff` inside the guest. 
-8. Issue `virsh start <guest-vm>`
-9. Now the new kernel image is booted.
-Additional information:
-XML:
-```
-<type arch='x86_64' machine='pc-q35-7.0'>hvm</type>
-    <kernel>/media/vm/libvirt/images/alpine-q/root/boot/vmlinuz-virt</kernel>
-    <initrd>/media/vm/libvirt/images/alpine-q/root/boot/initramfs-virt</initrd>
-    <cmdline>rootfstype=virtiofs root=root rw</cmdline>
-    <boot dev='hd'/>
-    <bootmenu enable='no'/>
-  </os>
-
-...
-
-    <filesystem type='mount' accessmode='passthrough'>
-      <driver type='virtiofs'/>
-      <binary path='/usr/libexec/virtiofsd' xattr='on'>
-        <cache mode='always'/>
-        <lock posix='on' flock='on'/>
-      </binary>
-      <source dir='/media/vm/libvirt/images/alpine-q/root'/>
-      <target dir='root'/>
-      <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/>
-    </filesystem>
-```
diff --git a/results/classifier/118/boot/1589 b/results/classifier/118/boot/1589
deleted file mode 100644
index 391e1f46..00000000
--- a/results/classifier/118/boot/1589
+++ /dev/null
@@ -1,40 +0,0 @@
-TCG: 0.966
-boot: 0.943
-device: 0.873
-graphic: 0.775
-semantic: 0.619
-mistranslation: 0.541
-register: 0.530
-PID: 0.520
-architecture: 0.479
-vnc: 0.449
-performance: 0.435
-debug: 0.416
-risc-v: 0.411
-files: 0.395
-ppc: 0.368
-user-level: 0.361
-arm: 0.313
-VMM: 0.288
-socket: 0.260
-permissions: 0.229
-network: 0.184
-i386: 0.137
-x86: 0.105
-peripherals: 0.105
-virtual: 0.089
-kernel: 0.078
-hypervisor: 0.078
-assembly: 0.059
-KVM: 0.035
-
-Crash when using qemu 8.0.0 version tcg mode
-Description of problem:
-Can I no longer use qemu in tcg mode?
-When operating in tcg mode in all versions of 8.0.0, a crash occurs on the booting screen and the window closes (the window stops responding before closing).
-Steps to reproduce:
-1. Run qemu with -accel tcg option
-2. enter the boot screen
-3. The screen freezes and the window closes after a few seconds (at which point it becomes unresponsive)
-Additional information:
-I have not checked whether the same symptom occurs in Linux, and it occurs in all versions of 8.0.0 for Windows.
diff --git a/results/classifier/118/boot/1589153 b/results/classifier/118/boot/1589153
deleted file mode 100644
index 58ddec92..00000000
--- a/results/classifier/118/boot/1589153
+++ /dev/null
@@ -1,79 +0,0 @@
-boot: 0.924
-socket: 0.868
-virtual: 0.852
-performance: 0.846
-x86: 0.842
-device: 0.827
-hypervisor: 0.801
-files: 0.790
-KVM: 0.767
-mistranslation: 0.756
-semantic: 0.740
-VMM: 0.732
-kernel: 0.731
-architecture: 0.718
-graphic: 0.713
-user-level: 0.705
-network: 0.704
-ppc: 0.685
-vnc: 0.674
-permissions: 0.665
-register: 0.637
-peripherals: 0.622
-arm: 0.622
-debug: 0.616
-risc-v: 0.600
-PID: 0.515
-assembly: 0.514
-TCG: 0.483
-i386: 0.408
-
-qemu-system-x86_64 version 2.5.0 freezes during windows 7 installation in lubuntu 16.04
-
-Hi!
-
-I have been using qemu - kvm for several years in different versions of ubuntu (lubuntu). I am trying to migrate from 15.04 to 16.04 and am having a problem. In particular, on my machine (a samsung series 9 with dual core i7 processor and 8gb ram) the following commands worked in 15.04 but do not work in 15.10 and 16.04. FYI, I tested them on a clean machine, where I have created a 60GB image file in its own partition.. In particular, I am using the command to start installing windows 7 and it works in a clean install of 15.04 (yesterday) but not in 15.10 (yesterday) or 16.04 (the day before). I do not get any error messages in my xterminal when running this and do not know how to check for windows error messages. By not working I mean that after loading files it gets to a windows screen and then stays there forever.
-
-The command lines used to invoke qemu is:
-echo "*** Installing windows 7 virtual machine - Step 2"
-
-
-echo "*** Try command for slow mouse"
-export SDL_VIDEO_X11_DGAMOUSE=0
-
-sudo qemu-system-x86_64 \
-  -enable-kvm \
-  -machine pc,accel=kvm \
-  -cdrom  /home/Archives/Software/OperatingSystems.Windows7HP.64/Windows7HP64_Install.iso \
-  -boot d \
-  -net nic,macaddr=56:44:45:30:31:34 \
-  -net user \
-  -cpu host \
-  -vga qxl \
-  -spice port=5900,disable-ticketing \
-  -uuid 8373c3d6-1e6c-f022-38e2-b94e6e14e170 \
-  -smp cpus=2,maxcpus=3 \
-  -m 6144 \
-  -name DrPhilSS9AWin7VM \
-  -hda /mnt/Windows7Image/Windows7Guest.img \
-  -localtime \
-  -k en-us \
-  -usb \
-  -usbdevice tablet&
-sleep 10
-spicy --host 127.0.0.1 --port 5900
-
-Have a similar issue though on Ubuntu 14.04 (4.2.0-36-generic #42~14.04.1-Ubuntu)
-
-We use an automated appliance build process, to create qemu/KVM appliances.
-
-Ever since qemu 2.0.0+dfsg-2ubuntu1.24 security update, we are getting the same issue as mentioned above (Windows 7 Installation CD - X17-24281.iso, hangs after loading files).
-
-We had to pin to 2.0.0+dfsg-2ubuntu1.22 to resolve the issue.
-
-
-
-Please see http://ubuntuforums.org/showthread.php?t=2325843&p=13499322#post13499322 for a similar discussion and for a workaround.  But please note that to the best I can tell it is still a bug.
-
-Phil
-
diff --git a/results/classifier/118/boot/1605045 b/results/classifier/118/boot/1605045
deleted file mode 100644
index 4e05fa80..00000000
--- a/results/classifier/118/boot/1605045
+++ /dev/null
@@ -1,46 +0,0 @@
-boot: 0.858
-semantic: 0.835
-graphic: 0.820
-debug: 0.804
-performance: 0.791
-user-level: 0.747
-device: 0.731
-mistranslation: 0.680
-ppc: 0.652
-architecture: 0.635
-permissions: 0.605
-register: 0.594
-assembly: 0.576
-PID: 0.568
-peripherals: 0.542
-files: 0.522
-network: 0.511
-vnc: 0.489
-socket: 0.478
-kernel: 0.469
-TCG: 0.468
-hypervisor: 0.451
-x86: 0.434
-i386: 0.430
-risc-v: 0.428
-VMM: 0.425
-virtual: 0.408
-arm: 0.356
-KVM: 0.262
-
-input-linux enter key stuck and/or broken
-
-Using new input-linux evdev passthrough feature of qemu (qemu 2.6.0) causes enter key to be stuck down after executing a shell script to launch qemu guest, resulting in repeated new lines in terminal. After a certain point of guest boot, the enter key is no longer pressed. However, at least under Gnome on Wayland, when pressing both left+right Ctrl keys to return keyboard back to the host, the enter key no longer functions. The enter key continues to function when control is under the guest, but never returns to functionality in the host until a reboot is performed.
-
-To further clarify: when keyboard control is under the host, enter key does not work while all other keys seem to work normally. When control of keyboard is under guest, all keys work normally including the enter key under the guest. This seems to be related to the enter key being stuck pressed after hitting enter to initially execute qemu / guest launch.
-
-I would also like to add: after performing a shutdown in the guest OS, qemu terminates as normal and keyboard control is automatically passed back to the host. However, the enter key continues to not function until the host is restarted.
-
-I can confirm this bug on Linux 4.7.1 with QEMU 2.6.0.  A workaround is to change to a different TTY and then back to the X display, which fixes the enter key for the rest of the QEMU session.
-
-The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
-If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/boot/1638 b/results/classifier/118/boot/1638
deleted file mode 100644
index 7cd8f8a5..00000000
--- a/results/classifier/118/boot/1638
+++ /dev/null
@@ -1,49 +0,0 @@
-boot: 0.903
-graphic: 0.873
-device: 0.787
-debug: 0.702
-semantic: 0.614
-permissions: 0.567
-hypervisor: 0.549
-VMM: 0.544
-virtual: 0.533
-PID: 0.526
-risc-v: 0.491
-files: 0.481
-kernel: 0.480
-performance: 0.467
-vnc: 0.427
-ppc: 0.396
-KVM: 0.389
-architecture: 0.375
-i386: 0.368
-x86: 0.338
-user-level: 0.326
-arm: 0.320
-mistranslation: 0.316
-peripherals: 0.313
-network: 0.289
-TCG: 0.288
-socket: 0.267
-register: 0.194
-assembly: 0.099
-
-BUG: Segmentation fault when -object memory-backend-file use readonly=on, prealloc=on together
-Description of problem:
-Segmentation Fault while booting VM.
-Steps to reproduce:
-1. set qemu boot params to `-object memory-backend-file,id=mem1,readonly=on,prealloc=on,mem-path=<any-img-file>,size=4G`
-2.
-3.
-Additional information:
-It might not be a bug, probably a feature.
-The reason of this segfault is:
-readonly would mmap the backend file using PROT_READ, make it readonly,
-but the prealloc=on would touch_pages the memory mmaped by the file.
-SO the segfault happens.
-
-But there is no docs about this segfault condition (the readonly and prealloc cannot be used together.)
-
-And maybe there is a way to solve this problem, I think.
-Use mmap the memory backend file to PROT_READ|PROT_WRITE at the beginnning, after touch_pages, then mprotect the memory.
-change the prot to readonly if required.
diff --git a/results/classifier/118/boot/1652286 b/results/classifier/118/boot/1652286
deleted file mode 100644
index 86e7ef98..00000000
--- a/results/classifier/118/boot/1652286
+++ /dev/null
@@ -1,68 +0,0 @@
-boot: 0.921
-performance: 0.850
-device: 0.807
-ppc: 0.791
-PID: 0.788
-graphic: 0.782
-semantic: 0.730
-network: 0.721
-architecture: 0.718
-socket: 0.696
-register: 0.696
-kernel: 0.604
-permissions: 0.574
-hypervisor: 0.565
-files: 0.555
-vnc: 0.540
-x86: 0.489
-risc-v: 0.480
-assembly: 0.475
-debug: 0.433
-mistranslation: 0.423
-arm: 0.406
-TCG: 0.404
-VMM: 0.402
-peripherals: 0.372
-i386: 0.363
-user-level: 0.363
-virtual: 0.323
-KVM: 0.289
-
-QEMU manpages provoke man(1) "can't break line" warnings
-
-I noticed when I ran 'man qemu' for version 2.8.0 I am getting this back at the terminal;
-
-
-<standard input>:1674: warning [p 1, 188.5i, div `an-div', 0.2i]: can't break line
-<standard input>:1677: warning [p 1, 188.8i, div `an-div', 0.2i]: can't break line
-
-This still reproduces with current QEMU:
-
-$ man -l build/qemu.1 >/dev/null
-<standard input>:248: warning [p 3, 6.8i, div `an-div', 0.2i]: can't break line
-<standard input>:376: warning [p 5, 2.5i, div `an-div', 0.2i]: can't break line
-<standard input>:667: warning [p 8, 9.7i, div `an-div', 0.2i]: can't break line
-
-(and so on for more warnings)
-
-'man' produces these warnings when the input has a line which it is unable to cleanly line-break to fit in the output terminal (and so the number of warnings you get depends on the width of the terminal you're using). For instance this line:
-.IP "\fB\-boot [order=\fR\fIdrives\fR\fB][,once=\fR\fIdrives\fR\fB][,menu=on|off][,splash=\fR\fIsp_name\fR\fB][,splash\-time=\fR\fIsp_time\fR\fB][,
-
-has no spaces in the whole of the part after "-boot" so it will typically not line break cleanly.
-
-Ideally we would fix this by arranging to have the groff output include '\:' zero-width break points between the ']' and '[' in this kind of long line so that it knew where to wrap. But I don't know if this is easy/possible with how we're generating the manpages at the moment.
-
-In any case the warning is harmless and the hard-wrapped lines are not too unreadable, so this is a minor issue.
-
-
-Still happens with the new Sphinx-generated manpages, for exactly the same reason.
-
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/214
-
-
diff --git a/results/classifier/118/boot/1745 b/results/classifier/118/boot/1745
deleted file mode 100644
index b07461eb..00000000
--- a/results/classifier/118/boot/1745
+++ /dev/null
@@ -1,97 +0,0 @@
-boot: 0.935
-device: 0.921
-files: 0.865
-performance: 0.861
-ppc: 0.783
-hypervisor: 0.772
-architecture: 0.730
-graphic: 0.710
-permissions: 0.710
-kernel: 0.707
-network: 0.689
-socket: 0.689
-PID: 0.649
-debug: 0.601
-user-level: 0.600
-x86: 0.597
-peripherals: 0.578
-i386: 0.568
-VMM: 0.527
-risc-v: 0.522
-vnc: 0.515
-KVM: 0.492
-semantic: 0.486
-mistranslation: 0.468
-register: 0.465
-TCG: 0.457
-arm: 0.452
-virtual: 0.435
-assembly: 0.283
-
-qemu-system-sparc64 v8.0.2 failed to read the file system.
-Steps to reproduce:
-1. Run qemu-system-sparc64 with the following command line.
-  `qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2`
-2. The system will report a issue "Could not open option rom 'pflash0': No such file or directory"
-3. Then, enter the boot command on the boot loader.
-4. The command failed with following message.
-```
-Boot device: vdisk  File and args:
-Bad magic number in disk label
-Can't open disk label package
-
-Can't open boot device
-```
-Additional information:
-```
-$ qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2
-Could not open option rom 'pflash0': No such file or directory
-cpu Probing I/O buses
-
-
-Sun Fire T2000, No Keyboard
-Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
-OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
-[mo23723 obp4.20.0 #0]
-Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
-
-
-
-ok boot
-Boot device: vdisk  File and args:
-Bad magic number in disk label
-Can't open disk label package
-
-Can't open boot device
-
-ok
-```
-
-It works fine with the previous qemu-system-sparc64 version.
-
-```
-$ qemu-7.2.3/build/qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2
-cpu Probing I/O buses
-
-
-Sun Fire T2000, No Keyboard
-Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
-OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
-[mo23723 obp4.20.0 #0]
-Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
-
-
-
-ok boot
-Boot device: vdisk  File and args:
-Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
-FCode UFS Reader 1.12 00/07/17 15:48:16.
-Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
-Loading: /platform/sun4v/ufsboot
-SunOS Release 5.10 Version Generic_118822-23 64-bit
-Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
-Use is subject to license terms.
-Hostname: unknown
-
-unknown console login:
-```
diff --git a/results/classifier/118/boot/1826 b/results/classifier/118/boot/1826
deleted file mode 100644
index e99afbcf..00000000
--- a/results/classifier/118/boot/1826
+++ /dev/null
@@ -1,59 +0,0 @@
-boot: 0.967
-architecture: 0.955
-kernel: 0.943
-graphic: 0.938
-performance: 0.907
-device: 0.894
-peripherals: 0.849
-debug: 0.793
-semantic: 0.791
-ppc: 0.772
-user-level: 0.725
-x86: 0.702
-vnc: 0.675
-VMM: 0.671
-files: 0.668
-TCG: 0.658
-PID: 0.658
-risc-v: 0.647
-permissions: 0.646
-assembly: 0.645
-mistranslation: 0.565
-register: 0.563
-i386: 0.548
-virtual: 0.543
-arm: 0.536
-KVM: 0.532
-network: 0.514
-socket: 0.459
-hypervisor: 0.454
-
-Segfault in memory_region_dispatch_write()
-Description of problem:
-Several possible outcomes
-- Kernel freeze and rcu lockup messages.
-- segfault
- 
-For segfault, using gdb.
-```
-in memory_region_dispatch_write (mr=mr@entry=0x130013001300013, addr=addr@entry=176, data=dat@entry=0, op=op@entry=M0_42, attrs=...) at ../../softwmmu/memory.c:1515
-1515     if (mr->alias) {
-
-in memory_region_dispatch_write(  .. as above...)
-in io_writex(env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, mmu_idx=mmu_idx@entry=0, val=0, addr=addr@entry=18446744073699049648, retaddr=retaddr@entry=140736023420498, op=MO_32) at ../../accel/tcg/cputlb.c:1448
-in do_st_mmio_leN (env=env@entry=0x555556a84320, full=full@entry=0x7ffda010f630, val_le=<optmized out>, val_le@entry=0, addr=addr@entry=18446744073699049648, size=size@entry=4, mmu_idx=mmu_idx@entry=0, ra=140736023420498) at ../../accel/tcg/cputlb.c:2755
-in do_st_4 (ra=<optmized_out>, memop=<optimized out> mmu_idx=0, val=0, p=0x7ffff529c140, env=0x555556a84320) at ../../accel/tcg/cputbl.c:2921
-do_st4_mmu (env=0x555556a84320, addr=<optimized out> val=<optmized out>, oi=<otpmized out> ra=140736023420498) at ../../accel/tcg/cputlb.c:3006
-in code_gen_buffer()
-in cpu_tb_exec(..) //getting lazy on typing as seems unlikely anything useful beyond here.
-in cpu_loop_exec_tb()
-cpu_exec_loop
-in cpu_exec_setjmp()
-in cpu_exec()
-in tcg_cpus_exec()
-```
-Steps to reproduce:
-1. Boot.
-2. Use gdb to grab back trace after segfault.
-Additional information:
-Seems to segfault mid way through PCI enumeration in the kernel.  Which device seems to vary between runs.
diff --git a/results/classifier/118/boot/1840920 b/results/classifier/118/boot/1840920
deleted file mode 100644
index c3985cb3..00000000
--- a/results/classifier/118/boot/1840920
+++ /dev/null
@@ -1,44 +0,0 @@
-mistranslation: 0.998
-arm: 0.990
-architecture: 0.954
-boot: 0.933
-vnc: 0.931
-device: 0.873
-ppc: 0.827
-graphic: 0.711
-register: 0.618
-files: 0.617
-semantic: 0.613
-peripherals: 0.568
-kernel: 0.547
-risc-v: 0.532
-network: 0.515
-VMM: 0.456
-TCG: 0.416
-socket: 0.333
-performance: 0.323
-debug: 0.239
-assembly: 0.215
-i386: 0.193
-user-level: 0.191
-PID: 0.151
-virtual: 0.138
-permissions: 0.118
-x86: 0.098
-KVM: 0.057
-hypervisor: 0.020
-
-changelog 4.1 krenel typo
-
-The changelog for 4.1 subsection Arm has a typo (krenel --> kernel)
-https://wiki.qemu.org/ChangeLog/4.1#Arm
-
-At the following line:
-The i.mx7 PCI controller emulation has been improved so it can boot current Linux krenels 
-
-it should be:
-The i.mx7 PCI controller emulation has been improved so it can boot current Linux kernels
-
-Thanks for this report -- I've just updated the changelog page to fix the typo.
-
-
diff --git a/results/classifier/118/boot/1859106 b/results/classifier/118/boot/1859106
deleted file mode 100644
index 77ce0a50..00000000
--- a/results/classifier/118/boot/1859106
+++ /dev/null
@@ -1,82 +0,0 @@
-boot: 0.915
-device: 0.872
-user-level: 0.849
-graphic: 0.840
-architecture: 0.835
-peripherals: 0.800
-performance: 0.799
-x86: 0.797
-ppc: 0.744
-i386: 0.671
-files: 0.662
-socket: 0.649
-semantic: 0.637
-kernel: 0.633
-PID: 0.633
-vnc: 0.615
-TCG: 0.561
-register: 0.545
-mistranslation: 0.544
-risc-v: 0.543
-VMM: 0.539
-network: 0.532
-arm: 0.529
-virtual: 0.518
-permissions: 0.506
-hypervisor: 0.484
-debug: 0.431
-KVM: 0.358
-assembly: 0.318
-
-4.2 regression: ReactOS crashes on boot
-
-In QEMU 4.1.x and earlier, ReactOS can successfully boot, but starting with 4.2, it fails, instead coming up with an error "The video driver failed to initialize."
-
-This happens regardless of VM configuration (even -M pc-i440fx-4.1) and it works well with older versions of QEMU. bisecting QEMU to find the first bad commit reveals 0221d73ce6a8e075adaa0a35a6ef853d2652b855 as the culprit, which is updating the seabios version; perhaps this bug belongs there, but I don't know the appropriate avenue (it seems seabios is a subproject of QEMU anyway?).
-
-I should add, ReactOS can be downloaded from here: https://reactos.org/download
-
-The LiveCD is sufficient to see the problem.
-
-Possibly related thread:
-"Do we need a cpu with TSC support to run SeaBIOS?"
-https://<email address hidden>/msg11726.html
-
-The QEMU project is currently considering to move its bug tracking to
-another system. For this we need to know which bugs are still valid
-and which could be closed already. Thus we are setting older bugs to
-"Incomplete" now.
-
-If you still think this bug report here is valid, then please switch
-the state back to "New" within the next 60 days, otherwise this report
-will be marked as "Expired". Or please mark it as "Fix Released" if
-the problem has been solved with a newer version of QEMU already.
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
-This is still a problem with qemu 1:4.2-3ubuntu6.16 on 20.04, and can be reproduced with:
-
-curl -LO https://freefr.dl.sourceforge.net/project/reactos/ReactOS/0.4.13/ReactOS-0.4.13-live.zip
-unzip ReactOS-0.4.13-live.zip
-qemu-system-x86_64 -cdrom ReactOS-0.4.13-Live.iso -boot d -usb -device usb-tablet
-[Pick "LiveCD" in the boot menu]
-
-Which gives the error shown in the attached screenshot.
-
-I've changed the Status back to New.
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/475
-
-
-As a workaround, I have extracted bios.bin and vgabios-stdvga.bin from http://launchpadlibrarian.net/318981898/seabios_1.10.2-1ubuntu1_all.deb, passing -bios bios.bin to qemu and making sure vgabios-stdvga.bin is in the current working directory when running qemu in order for it to be used (seems like there is no command line option for qemu to specify the VGA bios).
-
-@th-huth Aha, thanks!
-
diff --git a/results/classifier/118/boot/1873338 b/results/classifier/118/boot/1873338
deleted file mode 100644
index 225ee4db..00000000
--- a/results/classifier/118/boot/1873338
+++ /dev/null
@@ -1,101 +0,0 @@
-boot: 0.908
-debug: 0.904
-semantic: 0.902
-graphic: 0.899
-user-level: 0.897
-performance: 0.892
-assembly: 0.892
-virtual: 0.890
-device: 0.887
-register: 0.885
-permissions: 0.882
-vnc: 0.873
-mistranslation: 0.863
-arm: 0.862
-architecture: 0.862
-risc-v: 0.859
-PID: 0.858
-files: 0.853
-peripherals: 0.844
-kernel: 0.840
-socket: 0.832
-VMM: 0.824
-hypervisor: 0.818
-ppc: 0.811
-network: 0.784
-TCG: 0.771
-KVM: 0.742
-i386: 0.659
-x86: 0.493
-
-Dos on the fly CD image replacement is not Working with DOS
-
-Im not able to exchange CD image on the fly (needed for some games). I messed with command like - in console(ATL+CRTL+2) eject ide1-cd0 and change ide-cd0 D:/Games/!Emulators/Dos-QEMU/ISOs/TestChangeISO.iso , but system so never able to find new CD data.. simply drive so empty.. but when i reboot virtual machine, new change image is now working.
-
-  Qemu 4.2.
-
-Does this work with other guests, like Windows 95/98 as far as you can tell? Is it only a problem in DOS? What exact version of DOS are you seeing the problem with?
-
-I tried Win98 virtual machine here its working fine, without reboot.
-
- Im using MS-DOS 7.1 - integrated within and Win9x and classic MSDEX or SHSUCDX drivers for CD-ROM, but o dpmt thing that it matters.
-
-I think I need a bit more detail, I'm sorry. Can you explain to me the full environment you are seeing the problem in?
-
-Host: Windows? Linux? what version? If Linux, what kernel version?
-Guest: what's the version of the guest you are running? Windows98, or a version of DOS directly?
-Command-line: What's the QEMU command line you used? An exact command line helps.
-
-If it works OK in Windows98 but you are using a version of DOS embedded in Windows98, can you describe exactly the circumstance in which you are seeing stale CDROM data, with steps on how to reproduce?
-
-When it "doesn't work", can you explain the exact behavior you are seeing, in which application(s)?
-
-
-
-Host: I tried both Windows (10 64bit 19.09) and Linux host (Mint 19.3 64bit, kernel 5.40) system it really doesnt matters.
-
-Guest: Windows 98 - has integrated MS-DOS 7.1 you can boot into it through boot menu, which could be set by meditation of MSDOS.SYS, but you can install MS-DOS 7.1 Standalone too, without Windows, its the same.
- https://winworldpc.com/product/ms-dos/7x
- What DOS is after set up through Autoexec.bat and config.sys files. 
- Using DOS 7.1 make sense, because its most modern and supporting FAT32 file system.
-
- There is Qemu starting line i doubt that it will help, you can simulate problem with any DOS machine.
-qemu-system-i386.exe ^
--m 64 ^
--hda HDDs\MS-DOS-Systen-5G.vmdk ^
--hdb HDDs\DosData20G.vmdk ^
--vga cirrus ^ 
--soundhw sb16,adlib,pcspk ^
--net nic,model=rtl8139 ^
--net tap,ifname=TAP ^
--cdrom Isos\dos71cd.iso ^
--k en-us
-
- With Windows 98 - i run just commands in monitor.. open my computer and open cd drive - content of cd is changed.. its the same as in all later OSes XP- to Win10. Its working as expected.
-
- DOS - i boot into dos with cd drive driver enabled (lest say MSCDEX).. i run monitor, change cd image.. a trying to access it lets say that is drive E.. So i write "E:" <ENTER> to command line. I get error that drive is not accessible.. (command line should be switched to E:\ and here i should be able use "dir" to get list of files) but when i reboot machine, i see new exchange cd content.. so its at least somehow working.
-  Problem is that some games and programs require change cd on the fly, so reboot is not solution.
-  
-   You can simulate right behavior with Vmware or Virtualbox machine.
-
-   Is you are not familar with MS-DOS, here are command to autoexec and config for enable use of cd-rom drive:
-https://superuser.com/questions/778716/install-a-cd-rom-driver-on-ms-dos
-
-  Problem is probably that present version of cd exchange simulation code is not good enough / compatible for MSCDEX or SHSUCDX DOS CD-ROM drivers.. to make same action as is exchange cd on physical computer.
-
-  Windows 98 and later are using other drivers for it of course..
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
-Its not incomplete. i gave lots of info.
-
-You need to reset the state from Incomplete to New after you've provided the information.
-
-
-This is an automated cleanup. This bug report has been moved to QEMU's
-new bug tracker on gitlab.com and thus gets marked as 'expired' now.
-Please continue with the discussion here:
-
- https://gitlab.com/qemu-project/qemu/-/issues/206
-
-
diff --git a/results/classifier/118/boot/1879590 b/results/classifier/118/boot/1879590
deleted file mode 100644
index bb4d9bf0..00000000
--- a/results/classifier/118/boot/1879590
+++ /dev/null
@@ -1,103 +0,0 @@
-boot: 0.878
-network: 0.863
-PID: 0.764
-graphic: 0.739
-architecture: 0.704
-device: 0.698
-socket: 0.670
-permissions: 0.665
-peripherals: 0.664
-mistranslation: 0.652
-files: 0.646
-virtual: 0.643
-user-level: 0.628
-debug: 0.603
-semantic: 0.599
-arm: 0.581
-hypervisor: 0.575
-performance: 0.546
-risc-v: 0.518
-kernel: 0.509
-ppc: 0.507
-vnc: 0.482
-register: 0.479
-VMM: 0.442
-assembly: 0.429
-TCG: 0.389
-i386: 0.382
-x86: 0.377
-KVM: 0.274
-
-Using qemu-system-sparc64 no network interface seems to exist
-
-Using boot command:
-
-qemu-system-sparc64 -M niagara -L /home/chrisp/sparc/S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=/home/chrisp/sparc/S10image/disk.s10hw2
-
-After I log into solaris system I see no network devices other than the loopback device.
-All the docs I can see suggest it should come up with a default network device that allows communication via the hosts network. Host is ubuntu 64bit.  
-
-root@giant:/home/chrisp/sparc# qemu-system-sparc64 -version
-QEMU emulator version 5.0.0
-Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
-
-
-dladm show-link
-ifconfig -a
-
-
-
-ok boot
-Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
-FCode UFS Reader 1.12 00/07/17 15:48:16.
-Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
-Loading: /platform/sun4v/ufsboot
-SunOS Release 5.10 Version Generic_118822-23 64-bit
-Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
-Use is subject to license terms.
-Hostname: unknown
-
-unknown console login: root
-Last login: Wed Feb  8 09:01:28 on console
-Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
-# dladm show-link
-# ifconfig -a
-lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
-        inet 127.0.0.1 netmask ff000000
-
-Unfortunately it's been a while and no one has added the proper support to qemu yet, see comments at:
-http://tyom.blogspot.com/2016/10/qemu-sun4vniagara-target-went-public.html
-Apparently the niagara PCI adapter has to be implemented and the firmware recompiled to enable it. 
-
-
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting older bugs to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" within the next 60 days (otherwise it will get
-closed as "Expired"). We will then eventually migrate the ticket auto-
-matically to the new system.
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/boot/1906181 b/results/classifier/118/boot/1906181
deleted file mode 100644
index 7f0617a4..00000000
--- a/results/classifier/118/boot/1906181
+++ /dev/null
@@ -1,76 +0,0 @@
-x86: 0.935
-boot: 0.933
-graphic: 0.914
-user-level: 0.786
-kernel: 0.780
-performance: 0.757
-peripherals: 0.757
-device: 0.747
-hypervisor: 0.705
-KVM: 0.667
-i386: 0.659
-architecture: 0.653
-register: 0.638
-permissions: 0.636
-files: 0.629
-PID: 0.626
-semantic: 0.611
-ppc: 0.606
-virtual: 0.553
-vnc: 0.548
-mistranslation: 0.528
-network: 0.525
-arm: 0.522
-TCG: 0.517
-VMM: 0.501
-assembly: 0.480
-risc-v: 0.463
-debug: 0.462
-socket: 0.397
-
-Mouse starts jumping wildly on guest desktop
-
-Sometimes mouse goes completely crazy and starts jumping around the guest desktop by itself and becomes completely unusable.
-
-This does not happen on every boot, only sometimes. It may be caused by some input combination but I haven't yet found any specific cause. It happens soon after the desktop has been loaded and rebooting seems to be the only way to resolve the situation.
-
-
-Guest: Kubuntu 20.04 64-bit (live), with KDE desktop
-Host: Arch Linux, with KDE desktop
-QEMU version: 5.1.0
-
-QEMU start command:
-qemu-system-x86_64 -enable-kvm -m 6G -cpu host -smp 3 -cdrom ./linux/kubuntu-20.04-desktop-amd64.iso -boot d -vga virtio -soundhw hda -display sdl,gl=on
-
-The QEMU project is currently moving its bug tracking to another system.
-For this we need to know which bugs are still valid and which could be
-closed already. Thus we are setting the bug state to "Incomplete" now.
-
-If the bug has already been fixed in the latest upstream version of QEMU,
-then please close this ticket as "Fix released".
-
-If it is not fixed yet and you think that this bug report here is still
-valid, then you have two options:
-
-1) If you already have an account on gitlab.com, please open a new ticket
-for this problem in our new tracker here:
-
-    https://gitlab.com/qemu-project/qemu/-/issues
-
-and then close this ticket here on Launchpad (or let it expire auto-
-matically after 60 days). Please mention the URL of this bug ticket on
-Launchpad in the new ticket on GitLab.
-
-2) If you don't have an account on gitlab.com and don't intend to get
-one, but still would like to keep this ticket opened, then please switch
-the state back to "New" or "Confirmed" within the next 60 days (other-
-wise it will get closed as "Expired"). We will then eventually migrate
-the ticket automatically to the new system (but you won't be the reporter
-of the bug in the new system and thus you won't get notified on changes
-anymore).
-
-Thank you and sorry for the inconvenience.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/boot/2034 b/results/classifier/118/boot/2034
deleted file mode 100644
index 9dabb873..00000000
--- a/results/classifier/118/boot/2034
+++ /dev/null
@@ -1,38 +0,0 @@
-boot: 0.958
-graphic: 0.935
-TCG: 0.904
-device: 0.794
-semantic: 0.723
-debug: 0.710
-performance: 0.658
-PID: 0.633
-files: 0.604
-socket: 0.602
-kernel: 0.575
-register: 0.527
-architecture: 0.511
-ppc: 0.492
-network: 0.490
-vnc: 0.473
-mistranslation: 0.450
-x86: 0.437
-i386: 0.390
-risc-v: 0.370
-VMM: 0.329
-arm: 0.321
-KVM: 0.308
-hypervisor: 0.282
-peripherals: 0.239
-virtual: 0.231
-user-level: 0.178
-permissions: 0.163
-assembly: 0.130
-
-ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu))
-Description of problem:
-```
-cat boot.log
-aarch64>**
-aarch64>ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu))
-aarch64>Bail out! ERROR:../accel/tcg/cpu-exec-common.c:56:cpu_loop_exit_atomic: assertion failed: (!cpu_in_serial_context(cpu))
-```
diff --git a/results/classifier/118/boot/2212 b/results/classifier/118/boot/2212
deleted file mode 100644
index cb54a1a5..00000000
--- a/results/classifier/118/boot/2212
+++ /dev/null
@@ -1,47 +0,0 @@
-boot: 0.958
-kernel: 0.952
-files: 0.909
-register: 0.907
-graphic: 0.904
-device: 0.898
-ppc: 0.869
-vnc: 0.852
-peripherals: 0.847
-socket: 0.800
-semantic: 0.742
-PID: 0.739
-performance: 0.735
-virtual: 0.731
-permissions: 0.673
-network: 0.656
-hypervisor: 0.615
-architecture: 0.592
-debug: 0.538
-i386: 0.480
-risc-v: 0.479
-VMM: 0.432
-arm: 0.403
-x86: 0.402
-TCG: 0.401
-KVM: 0.315
-mistranslation: 0.278
-user-level: 0.227
-assembly: 0.194
-
-"pci_hp_register failed with error -16" was found in Guest when launching VM with pci-bridge and "-machine q35"
-Description of problem:
-Host and guest config file configuration:
-  CONFIG_HOTPLUG_PCI_CPCI=y
-  CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
-  CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
-  CONFIG_HOTPLUG_PCI_SHPC=y
-Use this configuration kernel to boot QEMU, with the QEMU parameter "-machine q35 -device pci-bridge,id=bridge0,chassis_nr=1". After the guest boot, dmesg will display "shpchp 0000:00:04.0: pci_hp_register failed with error -16".
-Steps to reproduce:
-1.Boot QEMU
-
-2.Check dmesg in VM
-Additional information:
-Error log:
-[root@localhost ~]# dmesg | grep pci_hp_register
-[    0.723893] shpchp 0000:00:04.0: pci_hp_register failed with error -16
-[dmesg.log](/uploads/8ce302f996255544b4327d27ea4ac555/dmesg.log)
diff --git a/results/classifier/118/boot/2360 b/results/classifier/118/boot/2360
deleted file mode 100644
index fd0dfdfb..00000000
--- a/results/classifier/118/boot/2360
+++ /dev/null
@@ -1,60 +0,0 @@
-boot: 0.835
-architecture: 0.734
-files: 0.723
-device: 0.721
-performance: 0.591
-kernel: 0.583
-ppc: 0.581
-PID: 0.553
-user-level: 0.544
-TCG: 0.536
-socket: 0.534
-peripherals: 0.534
-register: 0.518
-vnc: 0.503
-x86: 0.497
-graphic: 0.492
-risc-v: 0.491
-debug: 0.471
-permissions: 0.439
-network: 0.438
-hypervisor: 0.423
-VMM: 0.375
-i386: 0.356
-semantic: 0.347
-arm: 0.337
-mistranslation: 0.294
-KVM: 0.175
-virtual: 0.155
-assembly: 0.145
-
-qemu-system-m68k: double mmu fault
-Description of problem:
-Shutting down Mac OS 7.5.3 after boot from CD image results in a double MMU fault.
-qemu: fatal: DOUBLE MMU FAULT
-
-D0 = 00000008   A0 = 22152a78   F0 = 7fff ffffffffffffffff  (         nan)\
-D1 = 40810000   A1 = 0000c190   F1 = 7fff ffffffffffffffff  (         nan)\
-D2 = 00010490   A2 = 000207a0   F2 = 7fff ffffffffffffffff  (         nan)\
-D3 = 0002befe   A3 = a88879d0   F3 = 7fff ffffffffffffffff  (         nan)\
-D4 = db6d0000   A4 = 00041a86   F4 = 7fff ffffffffffffffff  (         nan)\
-D5 = 00000000   A5 = 39ec4080   F5 = 7fff ffffffffffffffff  (         nan)\
-D6 = 00000001   A6 = 00053178   F6 = 7fff ffffffffffffffff  (         nan)\
-D7 = 07b6d258   A7 = 00000004   F7 = 7fff ffffffffffffffff  (         nan)\
-
-PC = 97f87008   SR = 2210 T:0 I:2 SI X---- \
-FPSR = 00000000 ---- \
-FPCR =     0000 X RN \
-A7(MSP) = 00000000   A7(USP) = 00000000 ->A7(ISP) = 00000004 \
-VBR = 0x00000000 \
-SFC = 0 DFC 5 \
-SSW 00000505 TCR 0000c000 URP 00000000 SRP 07fffa00 \
-DTTR0/1: f900c060/807fc040 ITTR0/1: f900c060/807fc040 \
-MMUSR 00000000, fault at fffffffc \
-Steps to reproduce:
-1. Boot from CD image
-2. Choose Shut down from the Special menu
-Additional information:
-Reproducing requires a quadra 800 rom file.\
-A CD image (f.e. SYSTEM_7-5-3-RETAIL.ISO) can be obtained here: https://macintoshgarden.org/apps/macintosh-os-755 \
-Also see here: https://gitlab.com/qemu-project/qemu/-/issues/2249
diff --git a/results/classifier/118/boot/2400 b/results/classifier/118/boot/2400
deleted file mode 100644
index ee848acd..00000000
--- a/results/classifier/118/boot/2400
+++ /dev/null
@@ -1,73 +0,0 @@
-boot: 0.916
-x86: 0.894
-performance: 0.873
-device: 0.871
-virtual: 0.867
-graphic: 0.840
-semantic: 0.832
-mistranslation: 0.829
-architecture: 0.758
-hypervisor: 0.723
-files: 0.721
-debug: 0.701
-i386: 0.671
-socket: 0.657
-network: 0.653
-arm: 0.636
-kernel: 0.613
-ppc: 0.577
-KVM: 0.555
-user-level: 0.537
-peripherals: 0.512
-PID: 0.489
-VMM: 0.488
-TCG: 0.442
-vnc: 0.436
-risc-v: 0.425
-register: 0.403
-permissions: 0.365
-assembly: 0.282
-
-Qemu fails to boot snapshot image if its header is qcow2 but its payload and backing image extension are luks
-Description of problem:
-Qemu fails to recognize snapshot image E:\\test_snapshot.qcow2 saying Volume is not in LUKS format
-
-You need three commands to reproduce:
-
-`qemu-img create -f luks --object secret,id=sec0,data=123 -o key-secret=sec0 E:\test.luks 1G`
-
-`qemu-img create --object secret,id=sec0,data=123 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 -b E:\test.luks -F luks E:\test_snapshot.qcow2`
-
-`qemu-system-x86_64 -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0 -object secret,id=sec0,data=123`
-
-This error is printed:
-
-`qemu-system-x86_64: -drive file=E:\test_snapshot.qcow2,format=luks,key-secret=sec0: Volume is not in LUKS format`
-
-But fourth command shows that payload of `E:\test_snapshot.qcow2` has LUKS format:
-
-`qemu-img info E:\test_snapshot.qcow2`
-
-\[output\]
-
-```bash
-virtual size: 1 GiB (1073741824 bytes)
-disk size: 2.25 MiB
-encrypted: yes
-cluster_size: 65536
-backing file: E:\test.luks
-backing file format: luks
-Format specific information:
-    compat: 1.1
-    compression type: zlib
-    lazy refcounts: false
-    refcount bits: 16
-    encrypt:
-        ivgen alg: plain64
-        detached header: false
-        hash alg: sha256
-        cipher alg: aes-256
-        uuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
-        format: luks
-        cipher mode: xts ...
-```
diff --git a/results/classifier/118/boot/2620 b/results/classifier/118/boot/2620
deleted file mode 100644
index ae1d9771..00000000
--- a/results/classifier/118/boot/2620
+++ /dev/null
@@ -1,39 +0,0 @@
-boot: 0.923
-device: 0.907
-graphic: 0.795
-vnc: 0.771
-socket: 0.596
-architecture: 0.585
-debug: 0.548
-VMM: 0.533
-register: 0.521
-mistranslation: 0.517
-arm: 0.425
-files: 0.423
-semantic: 0.399
-performance: 0.397
-peripherals: 0.377
-risc-v: 0.320
-network: 0.313
-ppc: 0.311
-hypervisor: 0.311
-permissions: 0.310
-TCG: 0.263
-PID: 0.256
-x86: 0.198
-user-level: 0.190
-i386: 0.174
-kernel: 0.139
-KVM: 0.097
-assembly: 0.089
-virtual: 0.046
-
-Freezes when installing NeXTSTEP 3.3 or OPENSTEP 4.2 RISC version in qemu-system-sparc
-Description of problem:
-
-Steps to reproduce:
-1.Boot from NeXTstep 3.3 or OPENSTEP 4.2 RISC ISO.  Works on real Sparcstation 5, 10, or 20
-2.Start OS install
-3.
-Additional information:
-
diff --git a/results/classifier/118/boot/2699 b/results/classifier/118/boot/2699
deleted file mode 100644
index 55f90dcd..00000000
--- a/results/classifier/118/boot/2699
+++ /dev/null
@@ -1,48 +0,0 @@
-x86: 0.993
-boot: 0.978
-vnc: 0.943
-device: 0.925
-debug: 0.908
-graphic: 0.874
-kernel: 0.864
-PID: 0.841
-peripherals: 0.817
-architecture: 0.811
-hypervisor: 0.772
-KVM: 0.757
-socket: 0.748
-virtual: 0.738
-risc-v: 0.731
-performance: 0.701
-files: 0.667
-register: 0.623
-ppc: 0.602
-TCG: 0.587
-network: 0.579
-VMM: 0.543
-arm: 0.508
-i386: 0.495
-semantic: 0.451
-permissions: 0.426
-mistranslation: 0.372
-user-level: 0.274
-assembly: 0.212
-
-kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9)
-Description of problem:
-QEMU 9.1.91 monitor - type 'help' for more information
-(qemu) kvm_mem_ioeventfd_del: error deleting ioeventfd: Bad file descriptor (9)
-test.sh: line 14: 105283 Aborted                 (core dumped) /usr/local/bin/qemu-system-x86_64 -M q35 -m 8G -smp 8 -cpu host -enable-kvm -device VGA,bus=pcie.0,addr=0x2 -drive file=//home/fedora-38.qcow2,media=disk,if=virtio -device virtio-net-pci,mac=00:11:22:33:44:00,netdev=id8cxFGH,id=idaFLYjy,bus=pcie.0,addr=0x7 -netdev tap,id=id8cxFGH,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -vnc :0 -monitor stdio -qmp tcp:0:5555,server,nowait
-Steps to reproduce:
-1. Boot a guest
-2. set_link false nic and set_link true nic
-
-{"execute": "qmp_capabilities"}
-{"return": {}}
-{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": false}}
-{"return": {}}
-{"execute": "set_link", "arguments": {"name": "idaFLYjy", "up": true}}
-
-3. Guest hit qemu core dump
-Additional information:
-
diff --git a/results/classifier/118/boot/2754 b/results/classifier/118/boot/2754
deleted file mode 100644
index 184d6d14..00000000
--- a/results/classifier/118/boot/2754
+++ /dev/null
@@ -1,56 +0,0 @@
-boot: 0.963
-vnc: 0.958
-network: 0.957
-debug: 0.953
-virtual: 0.952
-device: 0.947
-socket: 0.944
-architecture: 0.942
-graphic: 0.932
-VMM: 0.909
-performance: 0.891
-files: 0.877
-PID: 0.871
-ppc: 0.867
-TCG: 0.801
-arm: 0.784
-register: 0.755
-risc-v: 0.752
-permissions: 0.740
-semantic: 0.736
-hypervisor: 0.718
-peripherals: 0.688
-user-level: 0.688
-assembly: 0.665
-kernel: 0.654
-mistranslation: 0.624
-x86: 0.572
-i386: 0.346
-KVM: 0.309
-
-Virt-manager using QEMU exit in flash and return an I/O Error when attempting to create an loongarch64 QEMU virtual machine
-Description of problem:
-Cannot complete the installation:'Enter the end of the file when reading data:I/O Error'
-
-Traceback (most recent call last):
-  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 71, in cb_wrapper
-    callback(asyncjob, *args, **kwargs)
-    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
-  File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install
-    installer.start_install(guest, meter=meter)
-    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
-  File "/usr/share/virt-manager/virtinst/install/installer.py", line 726, in start_install
-    domain = self._create_guest(
-            guest, meter, initial_xml, final_xml,
-            doboot, transient)
-  File "/usr/share/virt-manager/virtinst/install/installer.py", line 667, in _create_guest
-    domain = self.conn.createXML(initial_xml or final_xml, 0)
-  File "/usr/lib64/python3.13/site-packages/libvirt.py", line 4545, in createXML
-    raise libvirtError('virDomainCreateXML() failed')
-libvirt.libvirtError: 'Enter the end of the file when reading data:I/O Error'
-Steps to reproduce:
-1.Click to create loongarch64 virtual machine using virt-manager
-2.Configure all arguments of virtual machine
-3.Then click start installation,then the error occurs.
-Additional information:
-
diff --git a/results/classifier/118/boot/2782 b/results/classifier/118/boot/2782
deleted file mode 100644
index d20fea00..00000000
--- a/results/classifier/118/boot/2782
+++ /dev/null
@@ -1,40 +0,0 @@
-boot: 0.845
-x86: 0.777
-architecture: 0.759
-device: 0.742
-graphic: 0.630
-semantic: 0.443
-performance: 0.419
-kernel: 0.399
-permissions: 0.393
-register: 0.352
-risc-v: 0.345
-debug: 0.340
-i386: 0.307
-mistranslation: 0.287
-socket: 0.253
-vnc: 0.250
-files: 0.190
-PID: 0.188
-hypervisor: 0.167
-network: 0.156
-peripherals: 0.120
-virtual: 0.120
-ppc: 0.111
-user-level: 0.105
-VMM: 0.060
-TCG: 0.042
-assembly: 0.039
-arm: 0.031
-KVM: 0.024
-
-WHPX won't enable x86_64v3 level instructions
-Description of problem:
-x86_64v3 support is not available inside guest
-Steps to reproduce:
-1. Boot the image
-2. Open terminal
-3. Run `/lib64/ld-linux-x86-64.so.2 --help` and check which levels are available in the output
-4. Or run `/lib64/ld-linux-x86-64.so.2 --list-diagnostics | grep isa` and check `isa_1` value (expected 7 for v3 (3 bits being set))
-Additional information:
-Due to this some Linux distribution, like Centos Stream 10, will not be able to boot with WHPX acceleration enabled.
diff --git a/results/classifier/118/boot/2810 b/results/classifier/118/boot/2810
deleted file mode 100644
index 3f3be041..00000000
--- a/results/classifier/118/boot/2810
+++ /dev/null
@@ -1,31 +0,0 @@
-boot: 0.801
-device: 0.789
-graphic: 0.407
-performance: 0.333
-risc-v: 0.296
-mistranslation: 0.240
-permissions: 0.234
-peripherals: 0.180
-semantic: 0.172
-arm: 0.096
-files: 0.083
-network: 0.075
-PID: 0.069
-architecture: 0.069
-hypervisor: 0.065
-debug: 0.049
-user-level: 0.039
-VMM: 0.032
-assembly: 0.028
-register: 0.025
-virtual: 0.020
-kernel: 0.018
-TCG: 0.017
-socket: 0.015
-ppc: 0.014
-vnc: 0.013
-KVM: 0.004
-i386: 0.003
-x86: 0.002
-
-Boot zboot images on riscv64 and loogarch64
diff --git a/results/classifier/118/boot/2863 b/results/classifier/118/boot/2863
deleted file mode 100644
index ea6c68e8..00000000
--- a/results/classifier/118/boot/2863
+++ /dev/null
@@ -1,31 +0,0 @@
-mistranslation: 0.971
-boot: 0.954
-ppc: 0.708
-vnc: 0.653
-risc-v: 0.645
-semantic: 0.573
-device: 0.573
-TCG: 0.517
-i386: 0.488
-KVM: 0.477
-performance: 0.474
-VMM: 0.469
-peripherals: 0.455
-network: 0.448
-arm: 0.415
-kernel: 0.386
-files: 0.381
-socket: 0.367
-graphic: 0.343
-architecture: 0.337
-PID: 0.333
-user-level: 0.308
-x86: 0.305
-register: 0.302
-hypervisor: 0.298
-assembly: 0.248
-virtual: 0.226
-permissions: 0.211
-debug: 0.125
-
-Invalid read reason: rejected
diff --git a/results/classifier/118/boot/2957 b/results/classifier/118/boot/2957
deleted file mode 100644
index 84e3ff65..00000000
--- a/results/classifier/118/boot/2957
+++ /dev/null
@@ -1,58 +0,0 @@
-boot: 0.932
-device: 0.899
-vnc: 0.877
-kernel: 0.844
-permissions: 0.799
-VMM: 0.782
-graphic: 0.778
-risc-v: 0.754
-files: 0.723
-PID: 0.710
-socket: 0.704
-register: 0.701
-ppc: 0.666
-semantic: 0.661
-mistranslation: 0.652
-network: 0.623
-debug: 0.618
-virtual: 0.602
-architecture: 0.576
-i386: 0.571
-TCG: 0.568
-hypervisor: 0.552
-arm: 0.525
-x86: 0.450
-peripherals: 0.384
-performance: 0.356
-KVM: 0.344
-user-level: 0.257
-assembly: 0.231
-
-qemu-system-riscv32: Some ROM regions are overlapping
-Description of problem:
-Booting the image produces:
-```
-qemu-system-riscv32: Some ROM regions are overlapping
-These ROM regions might have been loaded by direct user request or by default.
-They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
-Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
-
-The following two regions overlap (in the memory address space):
-  output/images/fw_jump.elf ELF program header segment 1 (addresses 0x0000000000000000 - 0x00000000000278cc)
-  mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)
-```
-Steps to reproduce:
-1. `make qemu_riscv32_virt_defconfig`
-2. `make`
-3. `qemu-system-riscv32 \
--M virt -nographic \
--bios output/images/fw_jump.elf \
--kernel output/images/Image \
--append "root=/dev/vda ro" \
--drive file=output/images/rootfs.ext2,format=raw,id=hd0 \
--device virtio-blk-device,drive=hd0 \
--netdev user,id=net0 -device virtio-net-device,netdev=net0`
-Additional information:
-Changing `-bios output/images/fw_jump.elf` to `-bios output/images/fw_jump.bin` or `-bios output/images/fw_dynamic.bin` resolves the issue.
-
-Similar issue observed elsewhere, e.g. here [https://github.com/riscv-software-src/opensbi/issues/372](https://github.com/riscv-software-src/opensbi/issues/372)
diff --git a/results/classifier/118/boot/2959 b/results/classifier/118/boot/2959
deleted file mode 100644
index 5a137acf..00000000
--- a/results/classifier/118/boot/2959
+++ /dev/null
@@ -1,107 +0,0 @@
-i386: 0.981
-boot: 0.949
-assembly: 0.936
-graphic: 0.838
-files: 0.836
-device: 0.835
-debug: 0.799
-performance: 0.793
-architecture: 0.771
-mistranslation: 0.735
-semantic: 0.733
-kernel: 0.730
-virtual: 0.649
-peripherals: 0.618
-vnc: 0.618
-socket: 0.608
-arm: 0.592
-PID: 0.573
-permissions: 0.543
-register: 0.529
-ppc: 0.506
-network: 0.474
-hypervisor: 0.430
-risc-v: 0.411
-VMM: 0.409
-user-level: 0.391
-TCG: 0.342
-x86: 0.325
-KVM: 0.265
-
-int 0x10 teletype output cuts final character in custom MBR on QEMU (i386 real mode)
-Description of problem:
-When using QEMU to test a custom bootloader in 16-bit real mode (i386), the BIOS interrupt `int 0x10` with AH=0x0E (teletype output) fails to display the last character of the printed message. For example, printing `"hello"` only renders `"hell"`.
-
-This happens only with this exact combination:
-
-real mode `int 0x10` teletype output
-
-message ends with `13, 10, 0`
-
-`QEMU` output cuts off the last character consistently
-
-All buffer and code logic has been verified to be correct. The same code, when run on Bochs or physical hardware, prints properly.
-Steps to reproduce:
-1.Assemble the following boot.asm:
-```nasm
-[org 0x7C00]
-[BITS 16]
-
-_start:
-    cli
-    xor ax, ax
-    mov ds, ax
-    mov es, ax
-    mov ss, ax
-    mov sp, 0x7C00
-
-    mov si, msg
-    call print
-
-    hlt
-    jmp $
-
-print:
-    pusha
-.loop:
-    lodsb
-    or al, al
-    jz .done
-    mov ah, 0x0E
-    int 0x10
-    jmp .loop
-.done:
-    popa
-    ret
-
-msg db 'hello', 13, 10, 0
-times 510 - ($ - $$) db 0
-dw 0xAA55
-```
-
-2. Compile and run:
-```bash
-$ nasm -f bin boot.asm -o boot.img
-$ qemu-system-i386 -nographic -boot a -drive format=raw,file=boot.img,index=0,if=floppy
-```
-
-3. Output will be:
-```text
-Booting from Floppy...
-hell
-```
-Expected output:
-```text
-Booting from Floppy...
-hello
-```
-Additional information:
-- Adding padding (extra 13, 10) does not solve the problem.
-
-- Confirmed that boot.img includes all bytes (xxd dump is correct).
-
-- Tested on multiple machines with same QEMU version.
-
-- May relate to VGA character output buffer not flushing after last INT 0x10?
-
-- This makes QEMU inaccurate for BIOS-level debugging of bootloaders.
diff --git a/results/classifier/118/boot/436 b/results/classifier/118/boot/436
deleted file mode 100644
index 308c52ee..00000000
--- a/results/classifier/118/boot/436
+++ /dev/null
@@ -1,31 +0,0 @@
-boot: 0.979
-device: 0.908
-performance: 0.851
-graphic: 0.599
-user-level: 0.348
-debug: 0.345
-permissions: 0.325
-mistranslation: 0.287
-semantic: 0.281
-ppc: 0.265
-PID: 0.259
-risc-v: 0.258
-vnc: 0.256
-hypervisor: 0.245
-network: 0.218
-virtual: 0.192
-arm: 0.179
-architecture: 0.168
-register: 0.154
-peripherals: 0.152
-VMM: 0.131
-files: 0.112
-socket: 0.078
-x86: 0.071
-i386: 0.069
-kernel: 0.032
-TCG: 0.026
-assembly: 0.013
-KVM: 0.004
-
-window 8 stuck during boot on Qemu
diff --git a/results/classifier/118/boot/475 b/results/classifier/118/boot/475
deleted file mode 100644
index 25c970d7..00000000
--- a/results/classifier/118/boot/475
+++ /dev/null
@@ -1,31 +0,0 @@
-boot: 0.938
-performance: 0.881
-device: 0.875
-risc-v: 0.680
-graphic: 0.622
-PID: 0.617
-register: 0.594
-arm: 0.577
-ppc: 0.570
-files: 0.516
-TCG: 0.484
-network: 0.464
-semantic: 0.456
-debug: 0.454
-architecture: 0.447
-mistranslation: 0.419
-vnc: 0.386
-user-level: 0.316
-socket: 0.264
-peripherals: 0.220
-permissions: 0.199
-hypervisor: 0.183
-virtual: 0.160
-VMM: 0.145
-i386: 0.114
-assembly: 0.090
-x86: 0.087
-kernel: 0.009
-KVM: 0.001
-
-4.2 regression: ReactOS crashes on boot
diff --git a/results/classifier/118/boot/499 b/results/classifier/118/boot/499
deleted file mode 100644
index 010e63c3..00000000
--- a/results/classifier/118/boot/499
+++ /dev/null
@@ -1,31 +0,0 @@
-boot: 0.869
-device: 0.824
-performance: 0.695
-network: 0.617
-arm: 0.587
-architecture: 0.525
-virtual: 0.454
-graphic: 0.386
-debug: 0.373
-PID: 0.339
-semantic: 0.297
-VMM: 0.284
-risc-v: 0.215
-TCG: 0.214
-register: 0.209
-permissions: 0.208
-files: 0.190
-vnc: 0.185
-ppc: 0.137
-mistranslation: 0.116
-peripherals: 0.116
-socket: 0.077
-KVM: 0.024
-i386: 0.016
-hypervisor: 0.013
-kernel: 0.011
-user-level: 0.009
-assembly: 0.004
-x86: 0.002
-
-booting a linux guest with qemu-system-sparc with icount enabled hangs
diff --git a/results/classifier/118/boot/622 b/results/classifier/118/boot/622
deleted file mode 100644
index 41f5a33d..00000000
--- a/results/classifier/118/boot/622
+++ /dev/null
@@ -1,31 +0,0 @@
-boot: 0.962
-virtual: 0.956
-device: 0.940
-VMM: 0.711
-hypervisor: 0.699
-architecture: 0.698
-graphic: 0.566
-performance: 0.554
-arm: 0.426
-register: 0.360
-debug: 0.331
-network: 0.304
-mistranslation: 0.286
-socket: 0.272
-semantic: 0.244
-vnc: 0.206
-assembly: 0.190
-permissions: 0.167
-files: 0.166
-user-level: 0.157
-ppc: 0.148
-PID: 0.100
-risc-v: 0.034
-peripherals: 0.033
-kernel: 0.019
-x86: 0.013
-TCG: 0.013
-i386: 0.011
-KVM: 0.001
-
-Mac OS X Cheetah Virtual Machine booting back into Mac OS 9 for no reason
diff --git a/results/classifier/118/boot/721825 b/results/classifier/118/boot/721825
deleted file mode 100644
index 144a3d97..00000000
--- a/results/classifier/118/boot/721825
+++ /dev/null
@@ -1,126 +0,0 @@
-semantic: 0.961
-assembly: 0.949
-mistranslation: 0.943
-boot: 0.935
-device: 0.934
-performance: 0.929
-PID: 0.926
-vnc: 0.916
-risc-v: 0.913
-arm: 0.911
-user-level: 0.883
-peripherals: 0.879
-debug: 0.875
-architecture: 0.866
-virtual: 0.863
-graphic: 0.843
-register: 0.837
-hypervisor: 0.830
-ppc: 0.825
-files: 0.816
-permissions: 0.804
-network: 0.793
-KVM: 0.756
-socket: 0.741
-VMM: 0.735
-TCG: 0.727
-kernel: 0.684
-x86: 0.627
-i386: 0.259
-
-VDI block driver bugs
-
-Chunqiang Tang reports the following issues with the VDI block driver, these are present in QEMU 0.14:
-
-"Bug 1. The most serious bug is caused by race condition in updating a new 
-bmap entry in memory and on disk. Considering the following operation 
-sequence. 
-  O1: VM issues a write to sector X
-  O2: VDI allocates a new bmap entry and updates in-memory s->bmap
-  O3: VDI writes data to disk
-  O4: The disk I/O for writing sector X fails
-  O5: VDI reports error to VM and returns.
-
-Note that the bmap entry is updated in memory, but not persisted on disk. 
-Now consider another write that immediately follows:
-  P1: VM issues a write to sector X+1, which locates in the same block as 
-the previously used sector X.
-  P2: s->bmap already has one entry for the block, and hence VDI writes 
-data directly without persisting the new s->bmap entry on disk.
-  P3: The write disk I/O succeeds
-  P4: VDI report success to VM, but the bitmap entry is still not 
-persisted on disk.
-
-Now suppose the VM powers off gracefully (i.e., the QEMU process quits) 
-and reboots. The second write to sector X+1, which is reported as finished 
-successfully, is simply lost, because the corresponding in-memory s->bmap 
-entry is never persisted on disk. This is exactly what FVD's testing tool 
-discovers. After the block device is closed and then re-opened, disk 
-content verification fails.
-
-This is just one example of the problem. Race condition plus host crash 
-also causes problems. Consider another example below.
-  Q1: VM issues a write to sector X
-  Q2: VDI allocates a new bmap entry and updates in-memory s->bmap
-  Q3: VDI writes sector X to disk and waits for the callback
-  Q4: VM issues a write to another sector X+1, which is in the same block 
-as sector X.
-  Q5: VDI sees the bitmap entry in s->bmap is already allocated, and 
-writes sector X+1 to disk.
-  Q6: Write to sector X+1 finishes, and VDI's callback is invoked.
-  Q7: VDI acknowledges to the VM the completion of writing sector X+1
-  Q8: After observing the completion of writing sector X+1, VM issues a 
-flush to ensure that sector X+1 is persisted on disk.
-  Q9: VDI finishes the flush and acknowledge the completion of the 
-operation.
-  Q10: ... (some other arbitrary operations, but the disk I/O for writing 
-sector X is still not finished....)
-  Q11: The host crashes
-
-Now the new bitmap entry is not persisted on disk, while both writing to 
-sector X+1 and the flush has been acknowledged as finished. Sector X+1 is 
-lost, which is a corruption. This problem exists even if it uses O_DSYNC. 
-The root cause of the problem is that, if a request updates in-memory 
-s->bmap, another request that sees this update assumes that the update is 
-already persisted on disk, which is not.
-
-Bug 2: Similar to the bugs the FVD testing tool found for QCOW2, there are 
-several cases of the code below on failure handling path without setting 
-error return code, which mistakenly reports failure as success. This 
-mistake is caught by FVD when doing image content validation.
-       if (acb->hd_aiocb == NULL) {
-           /* missing     ret = -EIO; */
-            goto done; 
-        } 
-
-Bug 3: Similar to the bugs the FVD testing tool found for QCOW2, 
-vdi_aio_cancel does not perform a complete clean up and there are several 
-related bugs. First, memory buffer is not freed, acb->orig_buf and 
-acb->block_buffer. Second, acb->bh is not cancelled. Third, 
-vdi_aio_setup() does not initialize acb->bh to NULL so that when a request 
-acb is cancelled and then later reused for another request, its acb->bh != 
-NULL and the new request fails in  vdi_schedule_bh(). This is caught by 
-FVD's testing tool, when it observes that no I/O failure is injected but 
-VDI reports a failed I/O request, which indicates a bug in the driver."
-
-http://permalink.gmane.org/gmane.comp.emulators.qemu/94340
-
-Is this still an issue with the latest version of QEMU, or could we close this bug nowadays?
-
-On Fri, May 19, 2017 at 8:36 PM, Thomas Huth <email address hidden> wrote:
-> Is this still an issue with the latest version of QEMU, or could we
-> close this bug nowadays?
-
-A quick check of block/vdi.c shows that error handling is still
-lacking.  Updates to in-memory data structures are not reverted if the
-write to disk fails.
-
-Let's leave this in case someone is interested in fixing the bugs
-sometime.  VDI is not used heavily and typically in read-only mode so
-these bugs are not urgent.
-
-
-Hi Stefan (Weil) - this bug is now assigned to you since more than 10 years ... do you still plan to tackle it at some point in time? If not, I'd suggest to unassign it. Also, it's been four years again since the last comment ... should we maybe close this as "Wont Fix" ?
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/boot/797 b/results/classifier/118/boot/797
deleted file mode 100644
index 83c930e4..00000000
--- a/results/classifier/118/boot/797
+++ /dev/null
@@ -1,39 +0,0 @@
-architecture: 0.945
-boot: 0.943
-graphic: 0.938
-arm: 0.933
-device: 0.884
-hypervisor: 0.495
-semantic: 0.493
-debug: 0.478
-mistranslation: 0.457
-register: 0.388
-permissions: 0.375
-peripherals: 0.356
-files: 0.347
-performance: 0.328
-risc-v: 0.320
-socket: 0.307
-PID: 0.291
-user-level: 0.273
-vnc: 0.252
-network: 0.236
-virtual: 0.211
-TCG: 0.194
-VMM: 0.148
-ppc: 0.145
-x86: 0.114
-assembly: 0.100
-i386: 0.049
-kernel: 0.044
-KVM: 0.015
-
-ARM64 hvf fails to boot Windows 11 on 6.2.0
-Description of problem:
-On QEMU v6.1.0 with patches from @agraf manually applied, Windows 11 boots fine from the VHDX. Now that the patches have been mainlined, I would expect it to work the same but it gets stuck at EFI (no Windows "spinner").
-Steps to reproduce:
-1. `brew install qemu`
-2. Download Windows 11 VHDX from https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64
-3. Run command from above.
-Additional information:
-
diff --git a/results/classifier/118/boot/822408 b/results/classifier/118/boot/822408
deleted file mode 100644
index 9c686f08..00000000
--- a/results/classifier/118/boot/822408
+++ /dev/null
@@ -1,100 +0,0 @@
-boot: 0.932
-architecture: 0.902
-device: 0.896
-performance: 0.890
-peripherals: 0.867
-semantic: 0.850
-graphic: 0.834
-i386: 0.825
-permissions: 0.810
-mistranslation: 0.808
-register: 0.806
-kernel: 0.803
-files: 0.793
-ppc: 0.774
-network: 0.773
-socket: 0.773
-PID: 0.770
-user-level: 0.763
-x86: 0.754
-hypervisor: 0.712
-assembly: 0.711
-debug: 0.682
-arm: 0.671
-risc-v: 0.669
-virtual: 0.603
-vnc: 0.600
-VMM: 0.545
-TCG: 0.501
-KVM: 0.438
-
-Unable to access disk image on mipsel host
-
-Something is wrong with hard disk images on MIPSel host.
-
-The host system is mips64el (Loongson cpu, Linux 2.6.39, eglibc 2.13)
-Tried Qemu 0.14.1 and 0.15.0-rc2, both compiled with GCC 4.6.0.
-
-First I was trying to install WinXP (i386-softmmu).
-Starting install, create partition, format (either quick and full), seems to complete, boom the error:
-
-"
-Setup was unable to format the partition.  The disk may be damaged.  Make sure the drive is switched on and properly connected to your computer.  If the disk is a SCSI disk, make sure your SCSI devices are properly terminated.  Consult your computer manual or SCSI adapter documentation for more information.
-
-You must select a different partition for Windows XP.
-To continue, press ENTER.
-"
-
-This happens with both raw and qcow2 image format.
-Tried 10Gb image, tried 16Gb one - no difference.
-
-On a x86 host, that formatting makes the image (qcow2) grow to about 81 Mb by the time it reaches 100% formatted (quick), but on mipsel it grows to 0.8Mb at the same time and the error appears.
-
-I tried the same installing of Windows in Qemu on x86 host and copied over the completed image.
-In that case it starts loading, but in the middle of the animation there is an error:
-
-"
-STOP: c0000221 Unknown Hard Error
-\Systemroot\System32\ntdll.dll
-"
-(or HAL.dll)
-
-So, i tried linux-0.2.img.bz2 from the Qemu site, and that fails too.
-Thus it's the minimal bug reproduction thing.
-
-During boot there are multiple errors like:
-"
-hda: dma_intr: status=0x41 { DriveReady Error }
-hda: dma_intr: error=0x04 { DriveStatusError }
-hda: Failed opcode was: unknown
-"
-
-It booted and kind of worked, there were weird glitches in every program.
-Unusable.
-
-Summarily, that suggest some error in hard disk emulation or back storage, specific either to MIPSel or non-x86 hosts.
-
-Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)?
-
-Well, that's a blast from the past.
-Still have the MIPS laptop in question (Lemote Yeeloong 8101b), got it running.
-
-Built Qemu 0.14.1, the bug is replicated as before.
-Built Qemu 2.9.0,  the bug is still replicated as before (but qemu is now about 100x slower for some reason).
-
-So it would appear that whatever the problem is, it never got solved in the last 5 years.
-
-Raw image (linux-0.2.img.bz2), can't quite test on WinXP any more since it's awfully slow.
-Still gives the same kinds of errors:
-hda: dma_intr: status=0x41 { DriveReady Error }
-hda: dma_intr: error=0x04 { DriveStatusError }
-hda: Failed opcode was: unknown
-
-Built with ./configure --target-list=i386-softmmu
-
-
-Triage-wise, both the laptop, the company and the CPU architecture lost the test of time and are at best collector's items these days, so unless the bug can be replicated on some modern MIPS system it's not worth bothering with.
-
-
-[Expired for QEMU because there has been no activity for 60 days.]
-
diff --git a/results/classifier/118/boot/87 b/results/classifier/118/boot/87
deleted file mode 100644
index b4251fd8..00000000
--- a/results/classifier/118/boot/87
+++ /dev/null
@@ -1,31 +0,0 @@
-boot: 0.960
-device: 0.925
-performance: 0.859
-mistranslation: 0.811
-risc-v: 0.638
-semantic: 0.599
-ppc: 0.587
-kernel: 0.582
-graphic: 0.539
-PID: 0.523
-VMM: 0.514
-KVM: 0.505
-user-level: 0.489
-i386: 0.455
-TCG: 0.449
-x86: 0.429
-permissions: 0.386
-debug: 0.369
-register: 0.348
-network: 0.312
-vnc: 0.308
-hypervisor: 0.305
-arm: 0.295
-peripherals: 0.275
-virtual: 0.272
-architecture: 0.269
-files: 0.220
-socket: 0.184
-assembly: 0.118
-
-doesn't clear screen on boot
diff --git a/results/classifier/118/boot/886 b/results/classifier/118/boot/886
deleted file mode 100644
index 24386f16..00000000
--- a/results/classifier/118/boot/886
+++ /dev/null
@@ -1,46 +0,0 @@
-boot: 0.951
-device: 0.935
-graphic: 0.880
-performance: 0.776
-vnc: 0.662
-i386: 0.588
-semantic: 0.584
-socket: 0.581
-PID: 0.568
-arm: 0.560
-architecture: 0.551
-x86: 0.537
-kernel: 0.456
-mistranslation: 0.453
-network: 0.444
-user-level: 0.392
-debug: 0.362
-VMM: 0.361
-risc-v: 0.320
-TCG: 0.310
-permissions: 0.284
-ppc: 0.210
-hypervisor: 0.163
-register: 0.144
-virtual: 0.118
-KVM: 0.095
-files: 0.092
-peripherals: 0.087
-assembly: 0.040
-
-OpenIndiana panics when using -accel hvf
-Description of problem:
-OpenIndiana panics on boot.
-
-```
-Loading unix...
-Loading /platform/i86pc/amd64/boot_archive...
-Loading /platform/i86pc/amd64/boot_archive.hash...
-Booting...
-OpenIndiana Hipster 2021.10 Version illumos-79a6379db8 64-bit
-
-panic[cpu0]/thread=fffffffffbc49060:
-```
-Steps to reproduce:
-1. Run given command
-2. Wait
diff --git a/results/classifier/118/boot/907 b/results/classifier/118/boot/907
deleted file mode 100644
index fafd36cf..00000000
--- a/results/classifier/118/boot/907
+++ /dev/null
@@ -1,37 +0,0 @@
-boot: 0.881
-graphic: 0.767
-device: 0.736
-files: 0.722
-mistranslation: 0.663
-x86: 0.660
-network: 0.556
-PID: 0.491
-debug: 0.489
-socket: 0.419
-semantic: 0.407
-performance: 0.388
-user-level: 0.329
-architecture: 0.314
-virtual: 0.285
-hypervisor: 0.248
-i386: 0.246
-ppc: 0.243
-peripherals: 0.235
-permissions: 0.228
-vnc: 0.207
-kernel: 0.201
-TCG: 0.197
-risc-v: 0.190
-arm: 0.174
-register: 0.174
-VMM: 0.150
-KVM: 0.136
-assembly: 0.103
-
-qemu-system-x86_64 -blockdev fails with "CURL: Error opening file" when supplied url of ISO file
-Steps to reproduce:
-1. Run: qemu-system-x86_64 -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true
-
-The command returns error: qemu-system-x86_64: -blockdev driver=https,url=https://archive.fedoraproject.org:443/pub/archive/fedora/linux/releases/28/Server/x86_64/os/images/boot.iso,node-name=libvirt-1-storage,auto-read-only=true,discard=unmap: CURL: Error opening file:
-Additional information:
-This bug is not present in qemu 6.1.0, it surfaced with an update to 6.2.0
diff --git a/results/classifier/118/boot/997 b/results/classifier/118/boot/997
deleted file mode 100644
index adbb05c8..00000000
--- a/results/classifier/118/boot/997
+++ /dev/null
@@ -1,47 +0,0 @@
-boot: 0.873
-virtual: 0.856
-performance: 0.853
-device: 0.846
-architecture: 0.783
-graphic: 0.705
-hypervisor: 0.696
-semantic: 0.678
-vnc: 0.662
-PID: 0.619
-ppc: 0.579
-network: 0.568
-permissions: 0.561
-peripherals: 0.556
-kernel: 0.530
-risc-v: 0.528
-TCG: 0.524
-files: 0.485
-register: 0.477
-x86: 0.469
-VMM: 0.465
-arm: 0.448
-debug: 0.448
-mistranslation: 0.425
-i386: 0.402
-socket: 0.372
-user-level: 0.322
-assembly: 0.304
-KVM: 0.204
-
-Iothread is stuck at 100% CPU usage with virtio-scsi on QEMU 7.0.0
-Description of problem:
-Starting with QEMU 7.0.0, the iothread associated attached to a virtio-scsi controller is stuck at 100% CPU usage. Bisected to: https://gitlab.com/qemu-project/qemu/-/commit/826cc32423db2a99d184dbf4f507c737d7e7a4ae
-
-- Works as expected without the iothread
-- No issue with virtio-blk + iothread
-- Same behavior regardless of io=threads/native/io_uring
-- Same behavior with default vs increased queue count
-- The issue is triggered when the guest OS initializes the virtio driver
-Steps to reproduce:
-1. Add virtio-scsi controller with iothread
-2. Boot VM
-3. Check per-thread CPU usage such as in htop
-Additional information:
-[fedora.log](/uploads/776fbf8e5b823d0ab326946684ef9022/fedora.log)
-
-[fedora.xml](/uploads/54879e5adfb227ddef79d382e86fc608/fedora.xml)
-- 
cgit v1.2.3