restructure results

45 files changed, 2069 insertions, 0 deletions

diff --git a/results/classifier/zero-shot/108/files/1028 b/results/classifier/zero-shot/108/files/1028
new file mode 100644
index 000000000..7a50a2fc4
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1028
@@ -0,0 +1,49 @@
+files: 0.969
+debug: 0.938
+graphic: 0.934
+device: 0.911
+performance: 0.880
+permissions: 0.782
+PID: 0.744
+semantic: 0.728
+socket: 0.694
+other: 0.680
+vnc: 0.621
+network: 0.560
+KVM: 0.420
+boot: 0.385
+
+Assert fail for RISC-V RVV vmv.v.x for e64, vl == vl_max on RV32 guest
+Description of problem:
+assert message:
+qemu/tcg/tcg-op-gvec.c:1714: tcg_gen_gvec_dup_i32: Assertion `vece <= MO_32' failed.
+
+For a e64 vmv.v.x, in the file trans_rvv.c.inc, function "trans_vmv_v_x", when s->vl_eq_vlmax is true, then "tcg_gen_gvec_dup_tl" (it's defined to tcg_gen_gvec_dup_i32 for RV32) is called. In "tcg_gen_gvec_dup_i32" the assert "tcg_debug_assert(vece <= MO_32) will be triggered, since vece == MO_64 for e64.
+Steps to reproduce:
+1.enable cfg.Zve64f
+
+2.Prepare a problem as set e64, vl == vl_max and use vmv.v.x, maybe as below
+```
+  li t0, -1,
+  vsetvli x0, t0, e64,m1,tu,mu
+  li t1, -1
+  vmv.v.x v0, t1
+```
+Additional information:
+Below is a possible solution if it's appropriate.
+```
+#if TARGET_LONG_BITS == 32
+            if (s->sew == 3) {
+                TCGv_i64 s1_i64 = tcg_temp_new_i64();
+                tcg_gen_ext_tl_i64(s1_i64, s1);
+                tcg_gen_gvec_dup_i64(s->sew, vreg_ofs(s, a->rd),
+                                     MAXSZ(s), MAXSZ(s), s1_i64);
+                tcg_temp_free_i64(s1_i64);
+            } else {
+#endif
+            tcg_gen_gvec_dup_tl(s->sew, vreg_ofs(s, a->rd),
+                                MAXSZ(s), MAXSZ(s), s1);
+#if TARGET_LONG_BITS == 32
+            }
+#endif
+```
diff --git a/results/classifier/zero-shot/108/files/1077806 b/results/classifier/zero-shot/108/files/1077806
new file mode 100644
index 000000000..6f89b2541
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1077806
@@ -0,0 +1,23 @@
+files: 0.928
+other: 0.847
+device: 0.789
+boot: 0.714
+vnc: 0.710
+graphic: 0.700
+semantic: 0.625
+performance: 0.623
+PID: 0.613
+socket: 0.596
+network: 0.530
+permissions: 0.526
+debug: 0.411
+KVM: 0.238
+
+Integrate Virtualbox/Qemu Guest booting as a desktop environment listing (request)
+
+I had seen this new way to install Chromium OS and "boot" it using LightDM's session select menu, and it made me think of an idea:
+
+What if you were able to boot virtual machines in the same manner? It would simplify the Ubuntu user's life GREATLY if they had easy access to a Windows VM that can synchronize their files to and fro (Guest additions) and not require a reboot to use it. Modern computers have more than enough power to do something like this, and it should be even easier if the system is using a dedicated virtual machine environment rather than a full blown desktop.
+
+I think this would make using Ubuntu a LOT less of a hassle for the new user who came from Windows :)
+
diff --git a/results/classifier/zero-shot/108/files/1093360 b/results/classifier/zero-shot/108/files/1093360
new file mode 100644
index 000000000..3bb5cd466
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1093360
@@ -0,0 +1,33 @@
+files: 0.957
+KVM: 0.904
+device: 0.847
+other: 0.818
+vnc: 0.763
+graphic: 0.726
+semantic: 0.691
+socket: 0.636
+network: 0.563
+boot: 0.525
+performance: 0.512
+permissions: 0.478
+debug: 0.469
+PID: 0.417
+
+files on microsoft iso images mounted to qemu VM  get stripped  from Version info. E.G. Microsoft UAG installation fails
+
+QEMU 0.9.0-0.14.1
+KVM 60-88-0.14.1
+there is a reference for a root cause, why installation of Microsoft UAG fails.
+http://blogs.technet.com/b/isablog/archive/2010/07/13/another-tmg-2010-installation-failure-with-error-0x80070643.aspx
+
+when checking available information on the mounted UAG ISO in my qemu machine, I realized simliar reduced information.
+this was found:
+using AQEMU 0.8.2 of 2011.07.27
+
+using QEMU 0.9.0-0.14.1 and KVM 60-88-0.14.1
+in an KVM managed  machine
+
+Can you still reproduce this problem wit the latest release of QEMU (currently version 2.9.0), or could we close this bug nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/files/1098 b/results/classifier/zero-shot/108/files/1098
new file mode 100644
index 000000000..1f011b9a3
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1098
@@ -0,0 +1,26 @@
+files: 0.973
+graphic: 0.957
+device: 0.930
+vnc: 0.836
+performance: 0.814
+PID: 0.771
+semantic: 0.719
+debug: 0.610
+permissions: 0.606
+socket: 0.560
+boot: 0.453
+network: 0.399
+other: 0.298
+KVM: 0.050
+
+make check failed at bios-tables-test
+Description of problem:
+run unit test "make check", failed at
+3/177 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test       ERROR           6.59s   killed by signal 6 SIGABRT
+Steps to reproduce:
+1. ./configure --target-list=x86_64-softmmu --disable-xen --enable-sdl --enable-docs --disable-capstone
+2. make -j check V=1
+Additional information:
+Looks like DSDT construction code has been changed but hasn't updated bios-table-test binaries.
+
+See attached diff file.[make_check_failure_dsdt_asl.diff](/uploads/9ed82fbb081863d8991fb0ea72446365/make_check_failure_dsdt_asl.diff)
diff --git a/results/classifier/zero-shot/108/files/1247478 b/results/classifier/zero-shot/108/files/1247478
new file mode 100644
index 000000000..a74bb33dd
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1247478
@@ -0,0 +1,49 @@
+files: 0.958
+graphic: 0.851
+device: 0.753
+performance: 0.733
+other: 0.695
+semantic: 0.598
+network: 0.576
+socket: 0.504
+PID: 0.476
+debug: 0.469
+vnc: 0.344
+permissions: 0.325
+boot: 0.280
+KVM: 0.086
+
+usb passthrough mass storage write data corruption
+
+the windows 7 professional guest writes to usb high speed mass storage devices connected via host-libusb
+in bulk packages of either size 20480 or 4096 (as far as the actual file data is concerned and
+except for the last packet for odd-sized files). The pattern is:
+3 times bulk out 20480
+1 time bulk out 4096
+
+and that repeats for files longer than 65536 bytes.
+
+the file on the usb disk is corrupted and it is always corrupt in the last 4096 bytes of each
+20480 byte sized transfer. that means a file is corrupt at 16384-20480 and 36864-40960 and
+57344-61440.
+and so on. and because the 4096 sized  bulk out is always error free, the next corrupt span is from
+81920-86016.
+
+the last 4096 bytes of the 20480 sized transfer is always identical to the first 4096 bytes of the same
+transfer.
+
+to reproduce: run windows7 guest on and pass through usb2.0 disk with host-libusb. write a large file.
+(possibly check the bulk transfer sizes with usbmon).
+note that attaching usb disks with hw/usb/dev-storage does work just fine.
+cannot reproduce with linux as it always writes just 4096 bytes and writes with a linux guest are
+always ok even with usb passthrough.
+
+it is apparently not a qemu bug, but either a libusb or (more likely) linux bug.
+it happens on linux 3.6 but not linux 3.4, with the difference of:
+(USBFS_CAP_NO_PACKET_SIZE_LIM | USBFS_CAP_BULK_SCATTER_GATHER)
+added to the hcd capabilities bitfield in 3.6
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? Did you report it to the libusb folks?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/files/1280 b/results/classifier/zero-shot/108/files/1280
new file mode 100644
index 000000000..bab532b5e
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1280
@@ -0,0 +1,23 @@
+files: 0.924
+boot: 0.866
+device: 0.835
+network: 0.741
+performance: 0.729
+graphic: 0.694
+PID: 0.693
+semantic: 0.678
+vnc: 0.602
+permissions: 0.600
+socket: 0.542
+debug: 0.469
+other: 0.204
+KVM: 0.054
+
+qemu-system-arm 7.1 can not boot my cortex-m55 image
+Steps to reproduce:
+```
+1.qemu-system-arm -cpu cortex-m55 -machine mps3-an547 -nographic -vga none -monitor none -semihosting -semihosting-config enable=on,target=native -kernel qemu_simu.elf
+2.arm-none-eabi-gdb -ex "target extended-remote localhost:1234" qemu_simu.elf
+```
+Additional information:
+[qemu_simu.tar.gz](/uploads/b8b3bf0f4868fdbb22b19027f685b4f0/qemu_simu.tar.gz)
diff --git a/results/classifier/zero-shot/108/files/1301 b/results/classifier/zero-shot/108/files/1301
new file mode 100644
index 000000000..0545b9ebe
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1301
@@ -0,0 +1,32 @@
+files: 0.987
+graphic: 0.979
+vnc: 0.947
+boot: 0.942
+device: 0.925
+performance: 0.867
+permissions: 0.846
+socket: 0.758
+debug: 0.679
+semantic: 0.649
+PID: 0.646
+network: 0.624
+other: 0.582
+KVM: 0.057
+
+qemu-system-ppc in Homebrew on macOS has mouse warps and ghost clicks
+Description of problem:
+The QEMU version in Homebrew (Intel macOS host, PowerPC Mac OS 9 guest) has random warping of the mouse cursor as well as ghost clicks which begin as soon as the operating system finishes loading. Video demonstration: https://youtu.be/DjXO0hwHArk
+
+Notably, the exact same version of the QEMU source code with the same build arguments built *outside* of the Homebrew environment does not have this issue. I copied the following arguments from the QEMU Homebrew formula, and tried building QEMU on the command line:
+
+    ../configure --prefix=/Users/josh/Desktop/qemu-homebrew-build --cc=clang --host-cc=clang --disable-bsd-user --disable-guest-agent --enable-capstone --enable-curses --enable-libssh --enable-slirp --enable-vde --enable-virtfs --enable-zstd --extra-cflags=-DNCURSES_WIDECHAR=1 --disable-sdl --smbd=/usr/local/sbin/samba-dot-org-smbd --disable-gtk --enable-cocoa --target-list=ppc-softmmu
+
+This creates a `qemu-system-ppc` binary which is 15MB in size and works perfectly. By contrast, the exact same build commands within the Homebrew build process create a binary which is 10MB in size (!!!) and has this mouse warping and ghost clicks issue. This occurs whether QEMU was installed with `brew install qemu` or `brew install --build-from-source qemu`. Providing the `--HEAD` argument also makes no difference. The list of linked libraries (via `otool -L qemu-system-ppc`) is the same between the two versions.
+
+The only way I can reproduce this issue outside of Homebrew is to dump the Homebrew environmental variables (with `env`) to a file and then set up those same environmental variables with the `source` command, after which the resulting `qemu-system-ppc` binary is now 10MB in size like the Homebrew version, and has the mouse issue like the Homebrew version. I'll attach the file with the Homebrew environmental variables. It seems that the issue must lie somewhere in there, but I'm really pushing the limits of my abilities, so I could definitely use some ideas and/or insights.
+Steps to reproduce:
+1. Install QEMU via `brew install qemu`
+2. Start QEMU with an image of Mac OS 9
+3. After the boot process completes, the issue manifests
+Additional information:
+[Homebrew_ENV_Variables.txt](/uploads/2393aed8f29fa9c32bcaca44281bd2a5/Homebrew_ENV_Variables.txt)
diff --git a/results/classifier/zero-shot/108/files/1388 b/results/classifier/zero-shot/108/files/1388
new file mode 100644
index 000000000..f5f384676
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1388
@@ -0,0 +1,29 @@
+files: 0.931
+device: 0.772
+graphic: 0.708
+performance: 0.629
+network: 0.591
+semantic: 0.578
+socket: 0.558
+permissions: 0.488
+PID: 0.431
+vnc: 0.404
+boot: 0.396
+debug: 0.388
+other: 0.317
+KVM: 0.287
+
+QEMU 7.2.0 - Update file repository with x86/x64 Windows installer
+Description of problem:
+In file repository
+
+https://qemu.weilnetz.de/w32/
+https://qemu.weilnetz.de/w64/
+
+are not availble Windows installer for x86 and x64 platform and QEMU final 7.2.0.
+
+The latest version is 7.2.0.RC4 (08.12.2022).
+
+Thanks.
+Steps to reproduce:
+
diff --git a/results/classifier/zero-shot/108/files/1461918 b/results/classifier/zero-shot/108/files/1461918
new file mode 100644
index 000000000..690bc7d1e
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1461918
@@ -0,0 +1,38 @@
+files: 0.941
+device: 0.924
+vnc: 0.891
+performance: 0.882
+boot: 0.878
+network: 0.820
+graphic: 0.815
+PID: 0.707
+permissions: 0.702
+socket: 0.690
+semantic: 0.614
+debug: 0.589
+other: 0.492
+KVM: 0.202
+
+guest hangs after use ethtool to set scatter-gather on
+
+On the guests,  i have a rtl8139 nic,  I use ethtool to set  scatter-gather on ( ethtool -K eth0 sg on ),
+after that,   at host side,  I  use scp to send a file into guest.  As a result, guest hang.
+At that point qemu is using 100% of one host CPU, about 100% guest.
+
+If guest is centOS6.5， with no problem.
+
+
+
+The guest system is Fedora release 19(Kernel 3.11.10-200.fc19.x86_64).
+
+host system is debian 7.1.
+Kernel:3.10.0
+Qemu: 2.3.0
+
+cmd:
+/boot/qemu-2.3.0-bin/qemu-system-x86_64 -vnc :13 -enable-kvm -name fedora -smp sockets=1,cores=2 -cpu core2duo -nodefaults -vga cirrus -k en-us -boot menu=on,splash-time=8000 -m 2048 -usb -drive file=/boot/vm-disk-1.qcow2,if=none,id=drive-ide0,cache=none,aio=native -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 -netdev type=tap,id=net0,ifname=200,script=/etc/kvm/vtp-bridge -device rtl8139,romfile=,mac=FE:FC:FE:5C:58:65,netdev=net0,bus=pci.0,addr=0x12,id=net0
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU and Fedora? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/files/1469 b/results/classifier/zero-shot/108/files/1469
new file mode 100644
index 000000000..b0fabd263
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1469
@@ -0,0 +1,63 @@
+files: 0.954
+semantic: 0.776
+vnc: 0.770
+debug: 0.766
+PID: 0.741
+device: 0.733
+socket: 0.621
+graphic: 0.601
+KVM: 0.590
+network: 0.579
+performance: 0.390
+boot: 0.375
+permissions: 0.251
+other: 0.149
+
+QEMU 7.2.0 - make install fail
+Description of problem:
+`[10055/10057] Generating docs/QEMU manual with a custom command
+[10056/10057] Generating docs/QEMU man pages with a custom command
+[10056/10057] Installing files.
+Traceback (most recent call last):
+  File "/home/clive/.local/bin/meson", line 5, in <module>
+    from mesonbuild.mesonmain import main
+ModuleNotFoundError: No module named 'mesonbuild'
+FAILED: meson-internal__install 
+/home/clive/.local/bin/meson install --no-rebuild
+ninja: build stopped: subcommand failed.
+make: *** [Makefile:165: run-ninja] Error 1
+[clive@localhost build]$ 
+`
+Steps to reproduce:
+1. as user in shell
+2. `wget https://download.qemu.org/qemu-7.2.0.tar.xz`
+2. `tar xvJf qemu-7.2.0.tar.xz`
+3. `cd qemu-7.2.0`
+4. `./configure`
+5. `make install`
+Additional information:
+installed meson via `pip3 --user`
+
+`pip3 --list` **Output** `meson version 1.0.0`
+
+**Using** - python version 3.11.1
+
+`ninja-build` installed via package manager `dnf` 
+
+**Using** - ninja-build version 1.8.2
+
+Used `dnf builddep` on `ninja-build`, `meson`, and `qemu-kvm` before and after installation confirming I have dependencies.
+
+ File "/home/clive/.local/bin/meson" contains
+```
+#!/usr/local/bin/python3.11
+# -*- coding: utf-8 -*-
+import re
+import sys
+from mesonbuild.mesonmain import main
+if __name__ == '__main__':
+    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])
+    sys.exit(main())
+
+
+```
diff --git a/results/classifier/zero-shot/108/files/1561 b/results/classifier/zero-shot/108/files/1561
new file mode 100644
index 000000000..d953d20d9
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1561
@@ -0,0 +1,42 @@
+files: 0.956
+semantic: 0.751
+graphic: 0.714
+PID: 0.545
+device: 0.542
+socket: 0.495
+performance: 0.481
+network: 0.471
+permissions: 0.341
+vnc: 0.327
+debug: 0.300
+boot: 0.242
+KVM: 0.191
+other: 0.120
+
+Compile QEMU 6.2.0 fail for file not found
+Description of problem:
+Compile QEMU failed with error message:
+```
+In file included from ../subprojects/libvhost-user/libvhost-user.c:45:
+../subprojects/libvhost-user/libvhost-user.h:23:10: Fatal error：standard-headers/linux/virtio_ring.h：no such file or directory
+   23 | #include "standard-headers/linux/virtio_ring.h"
+      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+```
+Steps to reproduce:
+1. Download qemu-6.2.0 tarball at https://download.qemu.org/qemu-6.2.0.tar.xz
+2. unzip the tarball to dir ```qemu-6.2.0```
+2. cd ```qemu-6.2.0```, and then ```./configure && make -j2```
+Additional information:
+In ```qemu-6.2.0/subprojects/libvhost-user/libvhost-user.c:45```, the included files are:
+
+```
+#include <stdint.h>
+#include <stdbool.h>
+#include <stddef.h>
+#include <poll.h>
+#include <linux/vhost.h>
+#include <pthread.h>
+#include "standard-headers/linux/virtio_ring.h"    
+```
+
+```standard-headers``` are in ```qemu-6.2.0/include/standard-headers/```, but above #include assume it's in the same dir of ```libvhost-user.c```.
diff --git a/results/classifier/zero-shot/108/files/1653577 b/results/classifier/zero-shot/108/files/1653577
new file mode 100644
index 000000000..8f1388074
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1653577
@@ -0,0 +1,24 @@
+files: 0.960
+permissions: 0.883
+device: 0.686
+other: 0.598
+graphic: 0.597
+network: 0.514
+semantic: 0.341
+socket: 0.313
+performance: 0.253
+boot: 0.178
+debug: 0.150
+vnc: 0.112
+PID: 0.103
+KVM: 0.084
+
+Ability to set umask for 9pfs
+
+We should be able to specify the umask for 9pfs so that files created by the guest can be accessed by other users on the host. Currently they're only accessible by the user running qemu (and of course, root).
+
+Cannot this be addressed by adjusting the umask in the host before starting QEMU ? And maybe also by adjusting the umask inside the guest if using the "passthrough" or "none" security model of the "local" fsdev backend ?
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/108/files/1673957 b/results/classifier/zero-shot/108/files/1673957
new file mode 100644
index 000000000..0d5e7d596
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1673957
@@ -0,0 +1,52 @@
+files: 0.986
+device: 0.984
+graphic: 0.983
+other: 0.964
+semantic: 0.957
+permissions: 0.947
+PID: 0.941
+performance: 0.933
+vnc: 0.923
+debug: 0.921
+socket: 0.855
+network: 0.843
+boot: 0.825
+KVM: 0.055
+
+virtfs: mapped-xattr on mount point
+
+With
+  -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2"
+in the qemu command line,
+  shared2 on /mnt/testbis type 9p (rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144)
+in the guest mount points, and
+  tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
+in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep /proc/config.gz), running qemu as user "vm-test", trying to "touch a" in /mnt/testbis on the VM fails with "Operation not supported". In addition, no file or directory actually present in the host's /tmp can be seen in the guest's /mnt/testbis.
+
+When trying to replace "/tmp" with "/tmp/aaa" on the host, with /tmp/aaa owned by root:root, still running qemu as vm-test, trying to run "ls" in the guest's /mnt/testbis fails with the weird "ls: reading directory '.': Cannot allocate memory", while the directory is empty.
+
+After a "chown vm-test /tmp/aaa", the guest can list the files (despite the permissions already allowing it to do so before), but still not write new files: "cannot touch 'b': Operation not supported".
+
+Do you have a pointer as to what is happening?
+
+PS: complete setup is running all this inside a qemu VM that I use for testing, I guess it shouldn't matter but saying it just in case
+
+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 all 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". Thank you and sorry for the inconvenience.
+
+
+Independent of the planned tracker transition: this issue would require more information by original reporter anyway.
+
+From the information provided so far, I cannot reproduce this problem, and the error messages don't look like common misconfigurations on host side like wrong permissions, AppArmor policies or something like that. Especially the error message "Cannnot allocate memory" looks weird to me. So I think there should at least be more details about the host system this was deployed on.
+
+Hmm… so this dates back quite long ago unfortunately, I had basically forgotten about this bug report as I had opened it while just experimenting with qemu.
+
+To the best of my recollection, this was happening with a NixOS, either 16.09, 17.03 or unstable, at an update that was probably within 0-2 months of the time I made the bug report.
+
+Now, I guess the best may be to just close as can't reproduce, as I no longer have the code originally used to trigger the issue anyway?
+
+Either way, thank you for your feedback!
+
+Thanks for your answer! ... since this is not reproducible anymore, I'm closing the ticket now.
+
diff --git a/results/classifier/zero-shot/108/files/1720747 b/results/classifier/zero-shot/108/files/1720747
new file mode 100644
index 000000000..40133231a
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1720747
@@ -0,0 +1,23 @@
+files: 0.975
+other: 0.935
+device: 0.877
+performance: 0.800
+graphic: 0.768
+network: 0.768
+PID: 0.721
+vnc: 0.712
+socket: 0.648
+boot: 0.641
+KVM: 0.601
+permissions: 0.581
+semantic: 0.575
+debug: 0.477
+
+cannot extract release tarball on case-insensitive filesystems
+
+Extracting the release tarball for qemu-2.10.0 results in an error on case-insensitive filesystems because of the files qemu-2.10.0/roms/u-boot/scripts/Kconfig and qemu-2.10.0/roms/u-boot/scripts/kconfig.
+
+All other files are extracted correctly, and the resulting source can be built correctly.
+
+But tar returns with an error, which creates difficulties when trying to automate the build process (e.g: homebrew).
+
diff --git a/results/classifier/zero-shot/108/files/1760262 b/results/classifier/zero-shot/108/files/1760262
new file mode 100644
index 000000000..278fa296a
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1760262
@@ -0,0 +1,74 @@
+files: 0.940
+performance: 0.931
+semantic: 0.928
+graphic: 0.905
+other: 0.903
+debug: 0.867
+permissions: 0.848
+PID: 0.832
+network: 0.810
+KVM: 0.805
+device: 0.799
+socket: 0.793
+boot: 0.724
+vnc: 0.694
+
+cmsdk-apb-uart doesn't appear to clear interrupt flags
+
+I have been writing a small operating system and using QEMU emulating the mps2-an385 board for some of my testing.
+
+During development of the uart driver I observed some odd behaviour with the TX interrupt -- writing a '1' to bit 0 of the INTCLEAR register doesn't clear the TX interrupt flag, and the interrupt fires continuously.
+
+It's possible that I have an error somewhere in my code, but after inspecting the QEMU source it does appear to be a QEMU bug. I applied the following patch and it solved my issue:
+
+From 9875839c144fa60a3772f16ae44d32685f9328aa Mon Sep 17 00:00:00 2001
+From: Patrick Oppenlander <email address hidden>
+Date: Sat, 31 Mar 2018 15:10:28 +1100
+Subject: [PATCH] hw/char/cmsdk-apb-uart: fix clearing of interrupt flags
+
+---
+ hw/char/cmsdk-apb-uart.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/hw/char/cmsdk-apb-uart.c b/hw/char/cmsdk-apb-uart.c
+index 1ad1e14295..64991bd9d7 100644
+--- a/hw/char/cmsdk-apb-uart.c
++++ b/hw/char/cmsdk-apb-uart.c
+@@ -274,6 +274,7 @@ static void uart_write(void *opaque, hwaddr offset, uint64_t value,
+          * is then reflected into the intstatus value by the update function).
+          */
+         s->state &= ~(value & (R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK));
++        s->intstatus &= ~(value & ~(R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK));
+         cmsdk_apb_uart_update(s);
+         break;
+     case A_BAUDDIV:
+-- 
+2.16.2
+
+
+
+Found in v2.12.0-rc1.
+
+Thanks for the bug report; I've submitted this patch (which is similar to but not quite the same as your fix):
+https://patchwork.ozlabs.org/patch/896715/
+
+Hopefully this will get into 2.12, but we're quite close to release now so it will depend on whether we need to spin an extra release candidate for some other reason.
+
+
+On Tue, Apr 10, 2018 at 11:45 PM, Peter Maydell
+<email address hidden> wrote:
+>
+> Thanks for the bug report; I've submitted this patch (which is similar to but not quite the same as your fix):
+> https://patchwork.ozlabs.org/patch/896715/
+>
+> Hopefully this will get into 2.12, but we're quite close to release now
+> so it will depend on whether we need to spin an extra release candidate
+> for some other reason.
+
+Thanks for looking into it.
+
+Patrick
+
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6670b494fdb23f74ecd9b
+
diff --git a/results/classifier/zero-shot/108/files/1761153 b/results/classifier/zero-shot/108/files/1761153
new file mode 100644
index 000000000..00c6feeb2
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1761153
@@ -0,0 +1,47 @@
+files: 0.949
+graphic: 0.912
+debug: 0.904
+network: 0.830
+performance: 0.816
+other: 0.814
+semantic: 0.783
+device: 0.740
+PID: 0.716
+permissions: 0.641
+vnc: 0.609
+socket: 0.567
+boot: 0.517
+KVM: 0.503
+
+qemu-user incorrect mmap for large files on 64bits host and 32bits executable.
+
+qemu-user seems to incorrectly mmap a file if the offset is > 4GiB and guest binary is 32 bits elf.
+
+See attached test program `test_mmap.c`.
+
+```
+$ gcc -g -m32 -march=i386 test_mmap.c -o test_mmap
+$ file test_mmap
+test_mmap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e36db05f4dfd8a9cfde8a969214a242c1f5a4b49, with debug_info, not stripped
+$ uname -a
+Linux localhost.localdomain 4.15.10-300.fc27.x86_64 #1 SMP Thu Mar 15 17:13:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
+$ qemu-i386 --version
+qemu-i386 version 2.10.1(qemu-2.10.1-2.fc27)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+$ ./test_mmap
+$ qemu-i386 test_mmap
+Incorrect data 1
+```
+
+Tested with qemu-i386 packaged in Fedora 27 and qemu-i386 compiled from git master (094b62cd9c)
+
+The issue was firstly detected on (more complex program) using qemu-arm (with 32bits binary) so it is probably a 32/64bits problem independently of the cpu family.
+
+
+
+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/zero-shot/108/files/1788 b/results/classifier/zero-shot/108/files/1788
new file mode 100644
index 000000000..9df964535
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1788
@@ -0,0 +1,44 @@
+files: 0.929
+debug: 0.892
+performance: 0.891
+device: 0.884
+other: 0.878
+graphic: 0.868
+semantic: 0.861
+network: 0.795
+vnc: 0.790
+permissions: 0.783
+PID: 0.745
+boot: 0.728
+socket: 0.726
+KVM: 0.711
+
+Floating point rounding fails on mps3-an547 amd cortex-m55 while using LLVM-embedded-toolchain-for-Arm and Picolibic.
+Description of problem:
+Rounding of long double gives unexpected result. Simple code as example:
+```
+#include <math.h>
+int main(void)
+{
+  long double value = -8.5L;
+  long rounded_value = lrintl(value);
+  if( -8 == rounded_value )
+  {
+    return 0;
+  }
+  return 1;
+}
+```
+Steps to reproduce:
+1. Checkout project: [LLVM-embedded-toolchain-for-ARM](https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm)
+2. Configure it with option -DLLVM_TOOLCHAIN_LIBRARY_VARIANTS=armv8.1m.main_hard_nofp_mve 
+3. Build project
+4. Run Picolbic tests with ninja picolibc_armv8.1m.main_hard_nofp_mve-test
+
+As a result long_double test fails with incorrect rounding.
+Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). 
+Issue is present since qemu version 7.1.
+Additional information:
+As a result long_double test fails with incorrect rounding.
+Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). 
+Issue is present since qemu version 7.1.
diff --git a/results/classifier/zero-shot/108/files/1809 b/results/classifier/zero-shot/108/files/1809
new file mode 100644
index 000000000..94477573f
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1809
@@ -0,0 +1,68 @@
+files: 0.926
+performance: 0.922
+PID: 0.895
+device: 0.881
+socket: 0.875
+boot: 0.806
+network: 0.762
+graphic: 0.755
+permissions: 0.708
+semantic: 0.696
+other: 0.575
+debug: 0.573
+vnc: 0.558
+KVM: 0.406
+
+config machine "virt-6.2" with qemu-system-aarch64,it report "mem is not supported by this machine type"
+Description of problem:
+When i config the machine with virt-6.2 and config the numa for cpu,it report "mem is not supported by this machine type",but with virt-5.0 it work well,the newer version virt not support it? It is bug or require hardware support?Or compile configure is not correctlly?
+
+when i create vm,get the error report as follow:
+ 
+virsh create test.xml
+```
+qemu unexpectedly closed the monitor: qemu-system-aarch64: -chardev socket,id=charmonitor,fd=34,server,nowait: warning: short-form boolean option 'server' deprecated
+Please use server=on instead
+qemu-system-aarch64: -chardev socket,id=charmonitor,fd=34,server,nowait: warning: short-form boolean option 'nowait' deprecated
+Please use wait=off instead
+configure accelerator virt-6.2 start
+machine init start
+2023-08-04T02:17:13.984797Z qemu-system-aarch64: -numa node,nodeid=0,cpus=0-3,mem=8192: Parameter -numa node,mem is not supported by this machine type
+Use -numa node,memdev instead
+
+```
+
+
+I use qmp command "query-machines" get the result as follow:
+```
+{
+      "hotpluggable-cpus": true,
+      "name": "virt-6.2",
+     ** "numa-mem-supported": false,**
+      "default-cpu-type": "cortex-a15-arm-cpu",
+      "cpu-max": 512,
+      "deprecated": false,
+      "default-ram-id": "mach-virt.ram",
+      "alias": "virt"
+    },
+```
+
+I add the code "mc->numa_mem_supported = true;" in the api "virt_machine_6_1_options",it can supoort numa,but i don't know whether it is affected.
+
+```
+DEFINE_VIRT_MACHINE_AS_LATEST(6, 2)
+
+static void virt_machine_6_1_options(MachineClass *mc)
+{
+    VirtMachineClass *vmc = VIRT_MACHINE_CLASS(OBJECT_CLASS(mc));
+
+    virt_machine_6_2_options(mc);
+    compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len);
+    mc->smp_props.prefer_sockets = true;
+    vmc->no_cpu_topology = true;
+    **mc->numa_mem_supported = true;**
+
+    /* qemu ITS was introduced with 6.2 */
+    vmc->no_tcg_its = true;
+}
+```
diff --git a/results/classifier/zero-shot/108/files/1836453 b/results/classifier/zero-shot/108/files/1836453
new file mode 100644
index 000000000..854a325ef
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1836453
@@ -0,0 +1,52 @@
+files: 0.973
+socket: 0.947
+network: 0.929
+device: 0.889
+PID: 0.875
+graphic: 0.856
+debug: 0.844
+permissions: 0.841
+semantic: 0.839
+vnc: 0.838
+performance: 0.811
+KVM: 0.650
+boot: 0.622
+other: 0.378
+
+"qemu-nsis\*.bmp" -> no files found" when building with MXE
+
+Already reported for 4.0:
+https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg07005.html
+
+host: Docker qemu:debian-win32-cross
+
+$ make installer
+(cd /tmp/qemu-nsis; \
+         for i in qemu-system-*.exe; do \
+           arch=${i%.exe}; \
+           arch=${arch#qemu-system-}; \
+           echo Section \"$arch\" Section_$arch; \
+           echo SetOutPath \"\$INSTDIR\"; \
+           echo File \"\${BINDIR}\\$i\"; \
+           echo SectionEnd; \
+         done \
+        ) >/tmp/qemu-nsis/system-emulations.nsh
+makensis -V2 -NOCD \
+                -DCONFIG_DOCUMENTATION="y" \
+                 \
+                -DBINDIR="/tmp/qemu-nsis" \
+                 \
+                -DSRCDIR="/source/qemu" \
+                -DOUTFILE="qemu-setup-4.0.90.exe" \
+                -DDISPLAYVERSION="4.0.90" \
+                /source/qemu/qemu.nsi
+File: "/tmp/qemu-nsis\*.bmp" -> no files found.
+Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
+   /oname=outfile one_file_only)
+Error in script "/source/qemu/qemu.nsi" on line 122 -- aborting creation process
+Makefile:1077: recipe for target 'qemu-setup-4.0.90.exe' failed
+make: *** [qemu-setup-4.0.90.exe] Error 1
+
+Fix has been included here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b3ce38dcf93a1203
+
diff --git a/results/classifier/zero-shot/108/files/1877706 b/results/classifier/zero-shot/108/files/1877706
new file mode 100644
index 000000000..c8f6aee45
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1877706
@@ -0,0 +1,66 @@
+files: 0.937
+other: 0.905
+performance: 0.870
+semantic: 0.837
+device: 0.817
+graphic: 0.784
+vnc: 0.764
+boot: 0.760
+permissions: 0.759
+network: 0.737
+PID: 0.736
+socket: 0.689
+debug: 0.563
+KVM: 0.464
+
+ [Feature request] qemu does not support for Octeon MIPS64 on X86
+
+Description of problem:
+
+I use mips64-octeon-linux-gnu-gcc cross toolchain on X86,and generate binary file.
+
+> mips64-octeon-linux-gnu-gcc hello.c -static
+> file a.out
+> a.out: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, not stripped
+
+I execute it with mips64-linux-user mode in qemu, it is invalid.
+
+> ./qemu-5.0.0/mips64-linux-user/qemu-mips64 a.out
+> a.out: Invalid ELF image for this architecture
+
+when I choose mips-linux-user mode, it regards as illegal instruction.
+
+> ./qemu-5.0.0/mips-linux-user/qemu-mips a.out
+> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+> Illegal instruction (core dumped)
+
+I would like to know, is this due to my problem or does qemu not support Octeon MIPS64 on X86?
+
+if qemu has supported Octeon MIPS64 on X86, how can I emulate it.
+
+Probably not, but there may be a workaround. The closest cpu to Octeon that is supported in QEMU is "MIPS64R2-generic".
+
+Please try using switch -cpu MIPS64R2-generic in your QEMU command line.
+
+Also, I think you should use qemu-mipsn32 rather than qemu-mips or qemu-mips64.
+
+I don't have much hope that all this will work, but it is worth trying.
+
+
+
+
+
+
+Hi, Lu.
+
+Where can I download Octeon toolchain you used?
+
+I want to try it by myself.
+
+Aleksandar
+
+Was the MIPS64R2-generic good enough for you?
+
+If your file is "ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1",
+then you have to use the mipsn32-linux-user variant of QEMU (binary 'qemu-mipsn32').
+
diff --git a/results/classifier/zero-shot/108/files/1883414 b/results/classifier/zero-shot/108/files/1883414
new file mode 100644
index 000000000..9d1541c87
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1883414
@@ -0,0 +1,78 @@
+files: 0.970
+other: 0.908
+semantic: 0.892
+performance: 0.886
+graphic: 0.872
+vnc: 0.841
+KVM: 0.804
+debug: 0.784
+device: 0.749
+PID: 0.709
+permissions: 0.709
+network: 0.669
+boot: 0.587
+socket: 0.573
+
+Cannot build qemu-5.0.0 from tarball
+
+Cannot build qemu 5.0.0 from the release tarball. Building from git-clone succeeds.
+
+After downloading and unpacking the 5.0.0 tarball, I typed the following:
+
+mkdir build
+cd build
+../configure
+
+Then got the following error message:
+
+ERROR: missing file /home/uri/qemu-5.0.0/ui/keycodemapdb/README
+
+This is not a GIT checkout but module content appears to
+be missing. Do not use 'git archive' or GitHub download links
+to acquire QEMU source archives. Non-GIT builds are only
+supported with source archives linked from:
+
+  https://www.qemu.org/download/#source
+
+Developers working with GIT can use scripts/archive-source.sh
+if they need to create valid source archives.
+
+It appears the ui/keycodemapdb is missing some files that are obtained from a git submodule in a git tree.
+
+Building from a git clone succeeds.
+
+Where did you download the tarball from?
+
+I just tried it again it didn't reproduce - all files were there. I don't have the original tarball that caused me to open this bug, as I just moved to git clone and continued with that.
+
+Appologies and please close this bug.
+
+I can confirm this bug. I've got this tarball : https://github.com/qemu/qemu/archive/refs/tags/v5.2.0.zip
+
+and then I've unpacked it on /opt and then I did :
+
+./configure --prefix=/opt/qemu-5.2.0 --target-list=aarch64-softmmu,arm-softmmu --enable-guest-agent --enable-vnc --enable-vnc-jpeg --enable-vnc-png --enable-kvm --enable-spice --enable-sdl --enable-gtk --enable-virglrenderer --enable-opengl
+
+Using './build' as the directory for build output
+
+ERROR: missing file /opt/qemu-5.2.0/ui/keycodemapdb/README
+
+This is not a GIT checkout but module content appears to
+be missing. Do not use 'git archive' or GitHub download links
+to acquire QEMU source archives. Non-GIT builds are only
+supported with source archives linked from:
+
+  https://www.qemu.org/download/#source
+
+Developers working with GIT can use scripts/archive-source.sh
+if they need to create valid source archives.
+
+You say "I've got this tarball : https://github.com/qemu/qemu/archive/refs/tags/v5.2.0.zip"
+
+You get an error message, and the message says:
+
+"Do not use 'git archive' or GitHub download links to acquire QEMU source archives".
+
+So, like it says, don't do that, go get your tarball from the QEMU website.
+
+
diff --git a/results/classifier/zero-shot/108/files/1885718 b/results/classifier/zero-shot/108/files/1885718
new file mode 100644
index 000000000..89bc2dd3a
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1885718
@@ -0,0 +1,82 @@
+files: 0.938
+socket: 0.848
+other: 0.825
+graphic: 0.816
+semantic: 0.802
+PID: 0.776
+device: 0.776
+debug: 0.736
+network: 0.681
+vnc: 0.642
+permissions: 0.631
+performance: 0.614
+boot: 0.581
+KVM: 0.560
+
+qemu/target/mips/op_helper.c:943:5: style:inconclusive: Found duplicate branches for 'if' and 'else'
+
+Source code is
+
+    if (other_tc == other->current_tc) {
+        tccause = other->CP0_Cause;
+    } else {
+        tccause = other->CP0_Cause;
+    }
+
+Thank you for reporting this!
+
+Believe it or not, this has been a know issue to us for a while. We contacted the original contributor, and he says he can't recall what he actually meant when he wrote the segment. We left it as is until he remembers. However, this seems not likely to happen, and probably we will issue a fix soon. In any case, it is good that you reported it, many thanks!
+
+You already reported that 6 months ago:
+https://bugs.launchpad.net/qemu/+bug/1856706
+
+From: Aleksandar Markovic <email address hidden>
+
+Remove the segment:
+
+      if (other_tc == other->current_tc) {
+          tccause = other->CP0_Cause;
+      } else {
+          tccause = other->CP0_Cause;
+      }
+
+Original contributor can't remember what was his intention.
+
+Fixes: 5a25ce9487 ("mips: Hook in more reg accesses via mttr/mftr")
+Buglink: https://bugs.launchpad.net/qemu/+bug/1885718
+Signed-off-by: Aleksandar Markovic <email address hidden>
+Message-Id: <email address hidden>
+Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+---
+Cc: Bug 1885718 <email address hidden>
+
+ target/mips/cp0_helper.c | 9 +--------
+ 1 file changed, 1 insertion(+), 8 deletions(-)
+
+diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
+index bbf12e4a97..de64add038 100644
+--- a/target/mips/cp0_helper.c
++++ b/target/mips/cp0_helper.c
+@@ -375,16 +375,9 @@ target_ulong helper_mftc0_entryhi(CPUMIPSState *env)
+ target_ulong helper_mftc0_cause(CPUMIPSState *env)
+ {
+     int other_tc = env->CP0_VPEControl & (0xff << CP0VPECo_TargTC);
+-    int32_t tccause;
+     CPUMIPSState *other = mips_cpu_map_tc(env, &other_tc);
+ 
+-    if (other_tc == other->current_tc) {
+-        tccause = other->CP0_Cause;
+-    } else {
+-        tccause = other->CP0_Cause;
+-    }
+-
+-    return tccause;
++    return other->CP0_Cause;
+ }
+ 
+ target_ulong helper_mftc0_status(CPUMIPSState *env)
+-- 
+2.21.3
+
+
+
diff --git a/results/classifier/zero-shot/108/files/1917940 b/results/classifier/zero-shot/108/files/1917940
new file mode 100644
index 000000000..8cfe50eb9
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1917940
@@ -0,0 +1,53 @@
+files: 0.935
+performance: 0.902
+semantic: 0.894
+device: 0.886
+boot: 0.848
+graphic: 0.822
+other: 0.820
+permissions: 0.742
+debug: 0.732
+PID: 0.632
+network: 0.609
+KVM: 0.509
+socket: 0.496
+vnc: 0.461
+
+-bios edk2-$arch-code doesn't work for x86
+
+Whilst creating a flash device is recommended, -bios <file> is extremely useful in many cases as it automatically searches $PREFIX/share/qemu rather than requiring the caller (be it a human or a script) to work out where that directory is for the QEMU being called and prepend it to the file name.
+
+Currently, all the x86 EDK2 FD code files are 3653632 bytes in size, or 0x37c000 bytes. However, for some reason I cannot find the answer to (I traced the code back to 7587cf44019d593bb12703e7046bd7738996c55c), x86's -bios only allows files that are multiples of 64K in size (x86_bios_rom_init), which would require the EDK2 ROMs to be rounded up to 0x380000 bytes. If I delete the check, QEMU is able to load the only-16K-multiple-sized EDK2 and boot an OS just fine. If I pad EDK2 with 16K of zeroes at the *start* (since the ROM gets mapped counting backwards), it also works just fine (but padding at the *end* doesn't). Please therefore either relax the check in x86_bios_rom_init or ensure the EDK2 binary is suitably padded.
+
+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/zero-shot/108/files/1939 b/results/classifier/zero-shot/108/files/1939
new file mode 100644
index 000000000..add09e6e0
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1939
@@ -0,0 +1,79 @@
+files: 0.934
+performance: 0.922
+semantic: 0.891
+PID: 0.845
+device: 0.823
+debug: 0.809
+graphic: 0.778
+socket: 0.749
+boot: 0.717
+permissions: 0.667
+network: 0.607
+KVM: 0.554
+other: 0.501
+vnc: 0.489
+
+qemu master git can no longer be compiled under MacOs Sonoma 14.0
+Description of problem:
+
+Steps to reproduce:
+Qemu master git fails to compile under MacOs M1/2, I already tested it with "git-bisect" "git bisect good" and "git bisect bad".All dependencies for qemu are fulfilled and were installed using Homebrew under MacOs.It fails with these commits:
+
+
+`>>>>> commit 7c3fb52bcdaef85b15a91b3ca4d1516f9d9b5402
+>>>>> Author: Paolo Bonzini <pbonzini@redhat.com>
+>>>>> Date: Tue Aug 8 20:28:25 2023 +0200
+>>>>>
+>>>>> configure: never use PyPI for Meson
+>>>>>
+>>>>> Since there is a vendored copy, there is no point in choosing
+>> online
+>>>>
+>>>>> operation.
+>>>>>
+>>>>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+>>
+>>>>>
+>>>>> configure | 6 ------
+>>>>> 1 file changed, 6 deletions(-)
+>>>>>`
+Additional information:
+Older sources Qemu 8.1 can be compiled without problems. The only thing that has changed is that I did a major system update and Xcode was also updated. Since then compiling on qemu master version 8.1.50 breaks.
+
+```
+`On branch master
+Your branch is up to date with 'origin/master'.
+
+nothing to commit, working tree clean
+Mac-Studio qemu % ./configure --target-list=ppc-softmmu
+Using './build' as the directory for build output
+python determined to be '/Library/Frameworks/Python.framework/Versions/3.10/bin/python3'
+python version: Python 3.10.8
+mkvenv: Creating non-isolated virtual environment at 'pyvenv'
+mkvenv: checking for tomli>=1.2.0
+mkvenv: installing tomli>=1.2.0
+mkvenv: checking for meson>=0.63.0
+mkvenv: installing meson==0.63.3
+mkvenv: checking for sphinx>=1.6
+mkvenv: checking for sphinx_rtd_theme>=0.5
+
+'sphinx==5.3.0' not found:
+• Python package 'sphinx' was not found nor installed.
+• mkvenv was configured to operate offline and did not check PyPI.
+
+
+Sphinx not found/usable, disabling docs.
+Disabling PIE due to missing toolchain support
+The Meson build system
+Version: 0.63.3
+Source dir: /Users/qemu
+Build dir: /Users/qemu/build
+Build type: native build
+Project name: qemu
+Project version: 8.1.50
+
+../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -Wl,--version`
+stdout:
+stderr: ld: unknown options: --version
+clang: error: linker command failed with exit code 1 (use -v to see invocation)`
+```
diff --git a/results/classifier/zero-shot/108/files/1991 b/results/classifier/zero-shot/108/files/1991
new file mode 100644
index 000000000..fb3ff8bd6
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/1991
@@ -0,0 +1,79 @@
+files: 0.942
+boot: 0.912
+graphic: 0.911
+socket: 0.905
+device: 0.895
+permissions: 0.887
+performance: 0.859
+PID: 0.836
+debug: 0.802
+semantic: 0.778
+KVM: 0.754
+network: 0.740
+vnc: 0.698
+other: 0.517
+
+error "hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached" in qemu-system-hppa
+Description of problem:
+The installation phase terminates with a failed assertion in qemu:
+```
+...
+Rebooting the system
+reboot: Restarting system
+SeaBIOS wants SYSTEM RESET.
+***************************
+**
+ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached
+Bail out! ERROR:../hw/pci-host/astro.c:671:astro_chip_write_with_attrs: code should not be reached
+Aborted (core dumped)
+```
+Steps to reproduce:
+```
+PATH=$HOME/inst-qemu/8.2.0-rc0/bin:$PATH
+```
+
+Create empty disk:
+```
+qemu-img create -f qcow2 t2sde.qcow2 10G
+```
+
+Pull kernel and initrd out of the installation CD:
+```
+sudo mount -r -t iso9660 -o loop t2-23.6-hppa-minimal-desktop-gcc-glibc.iso /mnt
+mkdir boot-for-install
+cp -p /mnt/boot/* boot-for-install/
+sudo umount /mnt
+```
+
+Run installer:
+```
+machine_args="-M C3700 -m 256"
+disk_args="-drive file=t2sde.qcow2,format=qcow2,id=hd0"
+net_args=""
+#display_args="-monitor stdio -display gtk"
+display_args="-nographic"
+common_args="$machine_args $disk_args $net_args $display_args"
+qemu-system-hppa $common_args \
+  -kernel boot-for-install/vmlinux-6.3.7-t2 -initrd boot-for-install/initrd-6.3.7-t2 \
+  -drive file=t2-23.6-hppa-minimal-desktop-gcc-glibc.iso,if=scsi,bus=0,unit=2,media=cdrom
+```
+
+```
+Serial terminal: <Enter> or console
+# install
+Partition:
+  fdisk
+  n p 1 <Enter> <Enter>
+  w
+On /dev/sda1: Create filesystem of type ext3 with mount point /
+Install the system
+Full install (all packages).
+Keyboard: us
+Root password: t2
+Time zone: Europe/Berlin
+Locale: --
+Finally: <Back>
+Then: <Exit>
+```
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/files/2000 b/results/classifier/zero-shot/108/files/2000
new file mode 100644
index 000000000..e7f8442b1
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2000
@@ -0,0 +1,60 @@
+files: 0.931
+device: 0.921
+socket: 0.878
+permissions: 0.875
+other: 0.872
+network: 0.829
+performance: 0.822
+vnc: 0.806
+graphic: 0.802
+PID: 0.797
+boot: 0.726
+semantic: 0.616
+debug: 0.588
+KVM: 0.361
+
+m68k: error "fatal: Unimplemented control register write 0x0 = 0x1"
+Description of problem:
+An attempt to run the NetBSD m68k kernel under QEMU crashes.
+The error message is:
+```
+qemu: fatal: Unimplemented control register write 0x0 = 0x1
+```
+Steps to reproduce:
+1. ```wget http://cdn.netbsd.org/pub/NetBSD/iso/9.3/NetBSD-9.3-mac68k.iso```
+2. Pull kernel out of the installation CD:
+```
+sudo mount -r -t iso9660 -o loop /home/bruno/vms/os-install-media/NetBSD-9.3-mac68k.iso /mnt
+cp /mnt/mac68k/binary/kernel/netbsd-GENERIC.gz .
+sudo umount /mnt
+chmod u+w netbsd-GENERIC.gz
+gunzip netbsd-GENERIC.gz
+```
+3. ```qemu-img create -f qcow2 netbsd93.qcow2 10G```
+4. ```qemu-system-m68k -m 256 -drive file=netbsd93.qcow2,format=qcow2,index=0 -nographic -kernel netbsd-GENERIC -cdrom NetBSD-9.3-mac68k.iso```
+
+It crashes like this:
+```
+qemu: fatal: Unimplemented control register write 0x0 = 0x1
+
+D0 = 00000001   A0 = 00000000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000000   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000000   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00330346   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 00002e14   SR = 2700 T:0 I:7 SI -----
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+  A7(MSP) = 00000000 ->A7(USP) = 00330346   A7(ISP) = 00000000
+VBR = 0x00000000
+SFC = 0 DFC 0
+SSW 00000000 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at 00000000
+Aborted (core dumped)
+```
+Additional information:
+
diff --git a/results/classifier/zero-shot/108/files/2117 b/results/classifier/zero-shot/108/files/2117
new file mode 100644
index 000000000..14d4657b6
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2117
@@ -0,0 +1,42 @@
+files: 0.923
+graphic: 0.775
+device: 0.763
+other: 0.643
+performance: 0.631
+semantic: 0.557
+PID: 0.548
+debug: 0.418
+permissions: 0.364
+boot: 0.360
+vnc: 0.351
+socket: 0.344
+network: 0.201
+KVM: 0.025
+
+Unraid, Ubuntu, 9P/virtio and memory issues
+Description of problem:
+I am running an Ubuntu VM on Unraid - which is using Qemu. I am exposing my shares through "9p Mode" to the VM.
+
+The logs shows:
+-fsdev local,security_model=passthrough,id=fsdev-fs0,path=/mnt/user/backup \
+-device '{"driver":"virtio-9p-pci","id":"fs0","fsdev":"fsdev-fs0","mount_tag":"backup","bus":"pci.1","addr":"0x0"}' \
+
+Inside Ubuntu, I mount the exposed shares like this:
+
+sudo mount -t 9p -o trans=virtio "backup" /media/share/backup
+
+I have a script that uses rsync to sync the files from these mounted shares onto an internal disk drive. 
+
+The issues that I am facing, is that rsync sometimes reports "cannot allocate memory":
+
+rsync: [sender] readdir("/media/share/backup/myfolder"): Cannot allocate memory (12)
+ 
+There are "ten thousands" of files in that folder hierarchy, but there are plenty of memory available on the VM (many GBs), so that is no issue. The next time I run the job, it might go through as normal. But I would like to get rid of these issues.
+
+The question is: Is there some kind of memory allocation/limit to the virtio/9p as well? If yes - is there some way to increase it to avoid these errors?
+Steps to reproduce:
+1. Mount as shown
+2. Run rsync on folder with lots of files
+3. See error
+Additional information:
+N/A
diff --git a/results/classifier/zero-shot/108/files/2205 b/results/classifier/zero-shot/108/files/2205
new file mode 100644
index 000000000..be4635fde
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2205
@@ -0,0 +1,65 @@
+files: 0.939
+device: 0.831
+other: 0.809
+PID: 0.787
+graphic: 0.718
+socket: 0.656
+semantic: 0.605
+debug: 0.603
+performance: 0.554
+network: 0.546
+vnc: 0.545
+permissions: 0.530
+boot: 0.391
+KVM: 0.127
+
+9p rootfs issues
+Description of problem:
+I've created qemu guest per https://wiki.qemu.org/Documentation/9p_root_fs guidelines. debootstrap fails on this guest.
+Steps to reproduce:
+```
+root@ubuntu-dev:~# debootstrap --arch amd64 --variant=minbase noble /var/tmp/new_root/
+I: Retrieving InRelease 
+I: Checking Release signature
+E: Error executing gpgv to check Release signature
+root@ubuntu-dev:~# 
+```
+Additional information:
+I noticed, that gpg key extracted by debootstrap from the InRelease is corrupted:
+```
+root@ubuntu-dev:~# head /var/tmp/new_root/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_noble_Release.gpg
+-----BEGIN PGP SIGNATURE-----
+-----BEGIN PGP SIGNATURE-----
+
+-----BEGIN PGP SIGNATURE-----
+-----BEGIN PGP SIGNATURE-----
+
+iQIzBAEBCgAdFiEE9uyzdiR07anSG3Aihxkg0ZkbyTwFAmXkbkUACgkQhxkg0Zkb
+-----BEGIN PGP SIGNATURE-----
+-----BEGIN PGP SIGNATURE-----
+
+root@ubuntu-dev:~# 
+```
+I also noticed that on the 9p filesystem appending to files corrupts them:
+```
+root@ubuntu-dev:~# echo 1 >/var/tmp/test
+root@ubuntu-dev:~# cat /var/tmp/test
+1
+root@ubuntu-dev:~# echo 2 >>/var/tmp/test
+root@ubuntu-dev:~# cat /var/tmp/test
+1
+1
+2
+root@ubuntu-dev:~# 
+```
+This is not happening on the tmpfs:
+```
+root@ubuntu-dev:~# echo 1 >/tmp/test
+root@ubuntu-dev:~# cat /tmp/test
+1
+root@ubuntu-dev:~# echo 2 >>/tmp/test
+root@ubuntu-dev:~# cat /tmp/test
+1
+2
+root@ubuntu-dev:~# 
+```
diff --git a/results/classifier/zero-shot/108/files/2238 b/results/classifier/zero-shot/108/files/2238
new file mode 100644
index 000000000..05ff6c82c
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2238
@@ -0,0 +1,62 @@
+files: 0.921
+graphic: 0.878
+PID: 0.838
+performance: 0.832
+device: 0.770
+semantic: 0.766
+network: 0.766
+socket: 0.747
+other: 0.697
+vnc: 0.692
+permissions: 0.675
+debug: 0.672
+KVM: 0.627
+boot: 0.620
+
+The `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` is not properly honored
+Description of problem:
+The `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` is not properly honored.
+Steps to reproduce:
+1. Register a callback with `qemu_plugin_register_vcpu_mem_cb()`
+2. In the callback, print the return of `qemu_plugin_mem_is_store()` (either `true` or `false`)
+3. Change the value of `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` and look whether the callback prints `true` and/or `false` to determine if this is inline with `rw`.
+
+In the callback, we don't we get what we asked for.
+
+| Requested with rw   | Observed in the callback   |
+|---------------------|----------------------------|
+| QEMU_PLUGIN_MEM_R   | Only writes                |
+| QEMU_PLUGIN_MEM_W   | Both reads and writes      |
+| QEMU_PLUGIN_MEM_RW  | Both reads and writes      |
+Additional information:
+In `plugin-gen.c`, line 497, there is the following function:
+
+```cpp
+static bool op_rw(const TCGOp *op, const struct qemu_plugin_dyn_cb *cb)
+{
+    int w;
+
+    w = op->args[2];
+    return !!(cb->rw & (w + 1));
+}
+```
+
+The issue described above seems to be caused by the `+ 1`. I removed it and got the expected results.
+
+This function is used in the same file, line 526, like this:
+
+```cpp
+        if (!ok(begin_op, cb)) {
+            continue;
+        }
+```
+
+This isn't consistent with `core.c`, line 509, where the same flag is checked like this:
+
+```cpp
+        if (!(rw & cb->rw)) {
+                break;
+        }
+```
+
+Inconsistent because of the `+1` and also because of `break`/`continue`.
diff --git a/results/classifier/zero-shot/108/files/2422 b/results/classifier/zero-shot/108/files/2422
new file mode 100644
index 000000000..a161315ba
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2422
@@ -0,0 +1,84 @@
+files: 0.974
+permissions: 0.945
+other: 0.930
+PID: 0.927
+graphic: 0.923
+performance: 0.908
+socket: 0.905
+device: 0.889
+semantic: 0.871
+debug: 0.855
+network: 0.828
+boot: 0.801
+vnc: 0.783
+KVM: 0.642
+
+`vill` not set after reserved `vsetvli` instruction usage
+Description of problem:
+The ["AVL encoding" section of the RISC-V V Spec 1.0](https://github.com/riscv/riscv-isa-manual/blob/main/src/v-st-ext.adoc#avl-encoding) states that a `vsetvli  x0,x0,...` that changes VLMAX is reserved and "Implementations may set `vill`" in this case. QEMU does not set `vill` in this case. Doing so would help detect code generation issues and non-portable code.
+
+Here is the quote from the spec:
+
+> When `rs1=x0` and `rd=x0`, the instruction operates as if the current
+> vector length in `vl` is used as the AVL, and the resulting value is
+> written to `vl`, but not to a destination register.  This form can
+> only be used when VLMAX and hence `vl` is not actually changed by the
+> new SEW/LMUL ratio.  Use of the instruction with a new SEW/LMUL ratio
+> that would result in a change of VLMAX is reserved.
+> Use of the instruction is also reserved if `vill` was 1 beforehand.
+> Implementations may set `vill` in either case.
+
+Note, I have not checked QEMU's behaviour for the other case mentioned in the quote: "Use of the instruction is also reserved if `vill` was 1 beforehand".
+Steps to reproduce:
+1. Create `test.c`
+```C
+#include <assert.h>
+
+/* Position of vill in vtype.  */
+
+#define VILL_BIT (__riscv_xlen - 1)
+
+/* Return true if vill is 1.  */
+
+int vill_set_p ()
+{
+  __UINT64_TYPE__ vtype;
+  asm volatile ("csrr %0, vtype" : "=r"(vtype));
+
+  return (vtype >> VILL_BIT) & 1;
+}
+
+/* Return true if vill is 0.  */
+
+int vill_clear_p ()
+{
+  return !vill_set_p ();
+}
+
+int main ()
+{
+  int vl;
+
+  assert (vill_clear_p ());
+
+  /* Valid: vl = VLMAX.  */
+  asm volatile ("vsetvli %0,zero,e64,m8,ta,ma\n" : "=r"(vl));
+  assert (vill_clear_p ());
+
+  /* Valid: vl and VLMAX not changed.  */
+  asm volatile ("vsetvli zero,zero,e64,m8,ta,ma\n");
+  assert (vill_clear_p ());
+
+  /* Reserved: Reduce VLMAX.  */
+  asm volatile ("vsetvli zero,zero,e64,m1,ta,ma\n");
+  assert (vill_set_p ());
+
+  return 0;
+}
+```
+2. Build `test.c` with `riscv32-unknown-elf-gcc test.c -o test -march=rv64gcv -mabi=lp64d`
+3. Run qemu with `qemu-riscv64 -cpu rv64,v=true test`
+4. The final assertion fails because executing the reserved `vsetvli` did not set `vill`
+```
+assertion "vill_set_p ()" failed: file "test.c", line 40, function: main
+```
diff --git a/results/classifier/zero-shot/108/files/2761 b/results/classifier/zero-shot/108/files/2761
new file mode 100644
index 000000000..1cf89f328
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2761
@@ -0,0 +1,23 @@
+files: 0.962
+graphic: 0.781
+device: 0.776
+vnc: 0.553
+boot: 0.549
+semantic: 0.519
+debug: 0.481
+PID: 0.405
+network: 0.343
+permissions: 0.249
+socket: 0.221
+performance: 0.184
+other: 0.145
+KVM: 0.027
+
+Emulation of x86_64 binary on ARM64 fails with "Unable to find a guest_base to satisfy all guest address mapping requirements"
+Description of problem:
+Virtualisation fails with error "Unable to find a guest_base to satisfy all guest address mapping requirements"
+
+```
+file   /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash
+/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, BuildID[sha1]=2938b076ebbc4ea582b8eb1ea5c3f65d7a1b6261, stripped
+```
diff --git a/results/classifier/zero-shot/108/files/2786 b/results/classifier/zero-shot/108/files/2786
new file mode 100644
index 000000000..038ee43cc
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2786
@@ -0,0 +1,26 @@
+files: 0.995
+device: 0.868
+graphic: 0.814
+semantic: 0.628
+performance: 0.500
+PID: 0.441
+boot: 0.274
+other: 0.261
+debug: 0.220
+vnc: 0.047
+permissions: 0.030
+network: 0.021
+socket: 0.007
+KVM: 0.005
+
+deleting files fails on vvfat (was: "error handling renames")
+Description of problem:
+When working with files, renaming or saving from IDE, QEMU halts with the error message: 
+
+"Error handling renames (-2)"
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+a previous del failed, the directories are not synced so the rename on the drive fails when the file with the target file name still exists on the real directory. So the real issue is a failed del.
diff --git a/results/classifier/zero-shot/108/files/2816 b/results/classifier/zero-shot/108/files/2816
new file mode 100644
index 000000000..622af25f1
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2816
@@ -0,0 +1,29 @@
+files: 0.994
+graphic: 0.889
+semantic: 0.822
+device: 0.787
+PID: 0.768
+debug: 0.712
+other: 0.693
+network: 0.658
+socket: 0.603
+permissions: 0.601
+boot: 0.581
+vnc: 0.575
+performance: 0.505
+KVM: 0.293
+
+qemu-9.2.1 windows can not load files if kernel is linux-6.13.x
+Description of problem:
+qemu-9.2 and 9.2.1 emulating windows-10 both gave this
+bug "externe exception 80000004." emulating windows-10
+when a program tries to load a file. 
+qemu emulating windows-10 runs without this bug when using
+kernel linux-6.12.14 and older.
+Steps to reproduce:
+1.start a prog, in my case sprint-layout-6.0, try to open/load a file.
+2.
+3.
+Additional information:
+Im not shure if the bug is with qemu or kernel.
+You can decide better what causes this bug.
diff --git a/results/classifier/zero-shot/108/files/2825 b/results/classifier/zero-shot/108/files/2825
new file mode 100644
index 000000000..46a521630
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2825
@@ -0,0 +1,52 @@
+files: 0.949
+device: 0.945
+performance: 0.929
+other: 0.908
+graphic: 0.889
+permissions: 0.887
+PID: 0.835
+semantic: 0.746
+network: 0.742
+debug: 0.740
+socket: 0.696
+vnc: 0.668
+boot: 0.659
+KVM: 0.483
+
+execveat with file descriptor and empty filename returns ENOENT when cross architectures
+Description of problem:
+On my x86_64 debian host (with binfmt_misc configured), when calling execveat with a fd , and empty pathname "", and flag AT_EMPTY_PATH. Then only x86_64 and x86 can be called normally, while programs of other architectures (arm64, arm, riscv64, etc.) will return ENOENT errors.
+
+I first encountered this problem when trying to run lxc-attach with qemu-aarch64. Its reference is [lxc/stable-6.0/src/include/fexecve.c#L30](https://github.com/lxc/lxc/blob/stable-6.0/src/include/fexecve.c#L30), which is the implementation of the fexecve function. So I wrote a simple test and compiled it with `x86_64/aarch64-linux-gnu-gcc -static test.c -o test`. execveat works fine when running natively or using qemu-x86_64/qemu-i386. When running versions for other architectures, using AT_EMPTY_PATH will result in ENOENT (No such file or directory); use /proc/self/fd/%d as the pathname and execve, it will work fine (like the rest part of the fexecve function). If binfmt_misc is turned off and run forign architectures ver, both calls will result in ENOEXEC (Exec format error).
+Steps to reproduce:
+1. Install qemu-user and binfmt_misc. Install gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc.
+2. Compile test.c with host gcc, then compile forign architectures ver with gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. like `gcc -static test.c -o test` and `aarch64-linux-gnu-gcc -static test.c -o test-aarch64`
+3. Run different versions of test
+4. To disable/enable binfmt, you can `echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64` or `echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64`
+5. Sample outputs
+
+```
+rrex@debian:~/Downloads$ ./test
+****Running to prepare execve
+fd=3
+File size: 772296 bytes
+
+execveat with AT_EMPTY_PATH:
+**Running in execve
+
+execveat with fd path: /proc/self/fd/3
+**Running in execve
+
+rrex@debian:~/Downloads$ qemu-aarch64 ./test-aarch64 
+****Running to prepare execve
+fd=3
+File size: 706104 bytes
+
+execveat with AT_EMPTY_PATH:
+!!execveat a fd failed with errno: No such file or directory
+
+execveat with fd path: /proc/self/fd/3
+**Running in execve
+```
+Additional information:
+#
diff --git a/results/classifier/zero-shot/108/files/2838 b/results/classifier/zero-shot/108/files/2838
new file mode 100644
index 000000000..bf9c9074b
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/2838
@@ -0,0 +1,23 @@
+files: 0.967
+device: 0.942
+graphic: 0.909
+network: 0.790
+vnc: 0.752
+socket: 0.708
+permissions: 0.636
+performance: 0.636
+debug: 0.617
+PID: 0.606
+boot: 0.584
+other: 0.471
+semantic: 0.416
+KVM: 0.005
+
+searchindex.js in HTML doc is not reproducible
+Description of problem:
+Builds should be reproducible, at least when `SOURCE_DATE_EPOCH` set to some value (see: <https://reproducible-builds.org/docs/source-date-epoch/>), but the QEMU HTML doc contains a file which isn't reproducible.
+Steps to reproduce:
+1. `guix build --no-grafts qemu && guix build --no-grafts --check --keep-failed qemu`
+2. `diffoscope /gnu/store/3kym1ykv9r8n0hgbihqllch9ph136zx1-qemu-8.2.2-doc{,-check}`
+Additional information:
+[diffoscope-log.txt](/uploads/ab19f184082f343635df4fa7ef26b12e/diffoscope-log.txt)
diff --git a/results/classifier/zero-shot/108/files/408 b/results/classifier/zero-shot/108/files/408
new file mode 100644
index 000000000..e6061d79b
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/408
@@ -0,0 +1,16 @@
+files: 0.957
+device: 0.869
+network: 0.794
+debug: 0.649
+other: 0.603
+socket: 0.602
+semantic: 0.573
+performance: 0.538
+vnc: 0.522
+boot: 0.490
+PID: 0.440
+graphic: 0.342
+KVM: 0.335
+permissions: 0.165
+
+DLLs not installing on 32bit version
diff --git a/results/classifier/zero-shot/108/files/459 b/results/classifier/zero-shot/108/files/459
new file mode 100644
index 000000000..3167f9b33
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/459
@@ -0,0 +1,50 @@
+files: 0.944
+PID: 0.876
+graphic: 0.796
+socket: 0.793
+vnc: 0.767
+device: 0.758
+other: 0.756
+permissions: 0.755
+semantic: 0.754
+performance: 0.740
+network: 0.649
+boot: 0.579
+KVM: 0.504
+debug: 0.497
+
+bcm2835_aux (raspi3) fails when the receive FIFO fills up
+Description of problem:
+When a bare-metal application on the `raspi3` board reads the `AUX_MU_STAT_REG` MMIO register while the device's buffer is at full receive FIFO capacity (i.e. `s->read_count == BCM2835_AUX_RX_FIFO_LEN`) the assertion `assert(s->read_count < BCM2835_AUX_RX_FIFO_LEN)` fails.
+
+The assertion in question is currently in line 141 of `hw/char/bcm2835_aux.c`: https://gitlab.com/qemu-project/qemu/-/blob/9c2647f75004c4f7d64c9c0ec55f8c6f0739a8b1/hw/char/bcm2835_aux.c#L141
+but in my current QEMU version, it seems that it was in line 140, but I don't think that has any implication on this error. If the below steps to reproduce are followed, the full output of a normal QEMU (no debugging output or anything) is simply:
+
+```text
+$ echo abcdefgh | qemu-system-aarch64 -M raspi3 -kernel kernel8.elf -serial null -serial stdio
+qemu-system-aarch64: /build/qemu-71DV4m/qemu-4.2/hw/char/bcm2835_aux.c:140: bcm2835_aux_read: Assertion `s->read_count < BCM2835_AUX_RX_FIFO_LEN' failed.
+Aborted (core dumped)
+```
+
+Notice, that there is nothing really wrong with the implementation, if for instance an application that uses the `AUX_MU_LSR_REG` instead to check whether input is available, everything works as expected. It really seems that just this assertion is wrong. Also notice that the [BCM2835 manual](https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf) (page 18) explicitly allows values inclusive 8.
+Steps to reproduce:
+1. write a minimal bare-metal application for aarch64 using below main file
+2. compile it with a decent aarch64 compiler, linker script and entry assembly as `kernel8.elf`
+3. `echo abcdefgh | qemu-system-aarch64 -M raspi3 -kernel kernel8.elf -serial null -serial stdio`
+4. QEMU crashes with the above state assertion error
+Additional information:
+Minimal bare-metal application (`main.c`):
+
+```c
+#define MMIO_BASE       0x3F000000
+#define AUX_MU_STAT     ((volatile unsigned int*)(MMIO_BASE+0x00215064))
+
+void main() {
+    while (1) {
+        // Just read STAT register to trigger the assertion error
+        *AUX_MU_STAT;
+    }
+}
+```
+
+Also see [kernel8.elf.zip](/uploads/b12ae2750d2df1bb8db2701f3145f653/kernel8.elf.zip) for a precompiled version of the above application.
diff --git a/results/classifier/zero-shot/108/files/562 b/results/classifier/zero-shot/108/files/562
new file mode 100644
index 000000000..472818387
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/562
@@ -0,0 +1,16 @@
+files: 0.961
+device: 0.791
+graphic: 0.667
+other: 0.657
+network: 0.651
+socket: 0.625
+performance: 0.609
+vnc: 0.598
+permissions: 0.565
+debug: 0.533
+PID: 0.517
+KVM: 0.506
+boot: 0.451
+semantic: 0.420
+
+`ShaderTranslator.h` and `ShaderTranslator.cpp` files are missing and are not in ANGLE_ROOT/src/libShaderTranslator
diff --git a/results/classifier/zero-shot/108/files/640 b/results/classifier/zero-shot/108/files/640
new file mode 100644
index 000000000..199ecda97
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/640
@@ -0,0 +1,21 @@
+files: 0.973
+graphic: 0.967
+device: 0.933
+debug: 0.892
+boot: 0.869
+other: 0.815
+performance: 0.810
+network: 0.649
+permissions: 0.626
+semantic: 0.608
+vnc: 0.582
+PID: 0.534
+socket: 0.513
+KVM: 0.037
+
+qemu-system-x86_64 behaving as 32 bits
+Description of problem:
+Qemu is throwing the error ```file '/grub/i386-pc/normal.mod' not found.``` and going into rescue mode while booting my pendrive with a dual boot installation from scratch from [link](https://wiki.archlinux.org/title/Multiboot_USB_drive).
+The files like normal.mod aren't in the i386-pc folder because it's a x86 architecture install. The path it was supposed to see it is ```/grub/x86_64-efi/normal.mod```
+Additional information:
+![image](/uploads/7700f57c0818f6063e4388fe394538ad/image.png)
diff --git a/results/classifier/zero-shot/108/files/64322995 b/results/classifier/zero-shot/108/files/64322995
new file mode 100644
index 000000000..00045ea16
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/64322995
@@ -0,0 +1,64 @@
+files: 0.941
+performance: 0.939
+device: 0.915
+network: 0.914
+semantic: 0.906
+graphic: 0.904
+other: 0.881
+PID: 0.875
+socket: 0.866
+debug: 0.837
+permissions: 0.835
+vnc: 0.801
+boot: 0.780
+KVM: 0.742
+
+[Qemu-devel] [BUG] trace: QEMU hangs on initialization with the	"simple" backend
+
+While starting the softmmu version of QEMU, the simple backend waits for the
+writeout thread to signal a condition variable when initializing the output file
+path. But since the writeout thread has not been created, it just waits forever.
+
+Thanks,
+  Lluis
+
+On Tue, Feb 09, 2016 at 09:24:04PM +0100, Lluís Vilanova wrote:
+>
+While starting the softmmu version of QEMU, the simple backend waits for the
+>
+writeout thread to signal a condition variable when initializing the output
+>
+file
+>
+path. But since the writeout thread has not been created, it just waits
+>
+forever.
+Denis Lunev posted a fix:
+https://patchwork.ozlabs.org/patch/580968/
+Stefan
+signature.asc
+Description:
+PGP signature
+
+Stefan Hajnoczi writes:
+
+>
+On Tue, Feb 09, 2016 at 09:24:04PM +0100, Lluís Vilanova wrote:
+>
+> While starting the softmmu version of QEMU, the simple backend waits for the
+>
+> writeout thread to signal a condition variable when initializing the output
+>
+> file
+>
+> path. But since the writeout thread has not been created, it just waits
+>
+> forever.
+>
+Denis Lunev posted a fix:
+>
+https://patchwork.ozlabs.org/patch/580968/
+Great, thanks.
+
+Lluis
+
diff --git a/results/classifier/zero-shot/108/files/708 b/results/classifier/zero-shot/108/files/708
new file mode 100644
index 000000000..e65f60502
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/708
@@ -0,0 +1,25 @@
+files: 0.981
+boot: 0.915
+device: 0.839
+graphic: 0.802
+semantic: 0.699
+debug: 0.616
+vnc: 0.524
+network: 0.458
+other: 0.420
+PID: 0.399
+socket: 0.266
+performance: 0.254
+KVM: 0.161
+permissions: 0.051
+
+some TPM related files are missing in sysfs when enable passthrough TPM
+Description of problem:
+When enable passthrough TPM, there are some files in sysfs are missing, like description, uid file.
+under the host linux, we have those file in it:
+root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat description 
+TPM 2.0 Device
+root@intel-x86-64:/sys/class/tpm/tpm0/device/firmware_node# cat uid 
+1
+Steps to reproduce:
+after boot into system, check sysfs, there is no description and uid file in /sys/class/tpm/tpm0/device/firmware_node
diff --git a/results/classifier/zero-shot/108/files/753 b/results/classifier/zero-shot/108/files/753
new file mode 100644
index 000000000..fb84349ee
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/753
@@ -0,0 +1,16 @@
+files: 0.930
+performance: 0.898
+device: 0.891
+network: 0.701
+graphic: 0.545
+debug: 0.535
+semantic: 0.517
+vnc: 0.482
+boot: 0.451
+socket: 0.437
+permissions: 0.415
+PID: 0.400
+other: 0.338
+KVM: 0.002
+
+qemu unable to convert file above 2 TB
diff --git a/results/classifier/zero-shot/108/files/823 b/results/classifier/zero-shot/108/files/823
new file mode 100644
index 000000000..99f19a208
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/823
@@ -0,0 +1,36 @@
+files: 0.964
+graphic: 0.817
+device: 0.805
+PID: 0.765
+socket: 0.695
+semantic: 0.638
+performance: 0.511
+debug: 0.507
+network: 0.480
+vnc: 0.446
+permissions: 0.416
+other: 0.323
+boot: 0.255
+KVM: 0.163
+
+rcutorture: ../tests/unit/rcutorture.c:321: rcu_update_stress_test: Assertion `p != cp' failed.
+Description of problem:
+qemu rcutorture tests are failing when building qemu for Rawhide.  See the scratch build I did here and the follow log files:
+
+https://koji.fedoraproject.org/koji/taskinfo?taskID=81316487
+https://kojipkgs.fedoraproject.org//work/tasks/6509/81316509/build.log
+https://kojipkgs.fedoraproject.org//work/tasks/6508/81316508/build.log
+https://kojipkgs.fedoraproject.org//work/tasks/6510/81316510/build.log
+
+The full error is:
+
+```
+MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} G_TEST_SRCDIR=/builddir/build/BUILD/qemu-6.2.0/tests/unit G_TEST_BUILDDIR=/builddir/build/BUILD/qemu-6.2.0/qemu_kvm_build/tests/unit tests/unit/rcutorture --tap -k
+ERROR rcutorture - too few tests run (expected 2, got 0)
+rcutorture: ../tests/unit/rcutorture.c:321: rcu_update_stress_test: Assertion `p != cp' failed.
+make: *** [Makefile.mtest:1208: run-test-149] Error 1
+```
+Steps to reproduce:
+1. Compile qemu and run the test suite.
+Additional information:
+The only significant recent change since it was built successfully is adoption of GCC 12.  Could it be a change in compiler that causes this?
diff --git a/results/classifier/zero-shot/108/files/836 b/results/classifier/zero-shot/108/files/836
new file mode 100644
index 000000000..629b699e3
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/836
@@ -0,0 +1,100 @@
+files: 0.951
+performance: 0.948
+boot: 0.904
+graphic: 0.899
+device: 0.832
+PID: 0.809
+permissions: 0.762
+socket: 0.754
+network: 0.731
+debug: 0.697
+semantic: 0.638
+vnc: 0.624
+KVM: 0.552
+other: 0.332
+
+qemu-riscv32: Syscall LSEEK returns -14 (EFAULT)
+Description of problem:
+The lseek() system call returns -14 (EFAULT) if the file descriptor is correct,
+which it should never do (According to the lseek(2) man page).
+
+Here is some demonstrative code:
+```
+/* System Call numbers, according to https://github.com/riscv-software-src/riscv-pk/blob/master/pk/syscall.h */
+.set SYS_OPENAT,  0x38
+.set SYS_CLOSE,   0x39
+.set SYS_LSEEK,   0x3e
+.set SYS_READ,    0x3f
+.set SYS_WRITE,   0x40
+.set SYS_EXIT,    0x5d
+
+.set SEEK_CUR,    1
+
+/* According to https://elixir.bootlin.com/linux/v5.16.2/C/ident/AT_FDCWD */
+.set AT_FDCWD,    (-100)
+
+.section .text
+.global _start
+_start:
+
+/* Open the file with SYS_OPENAT, because SYS_OPEN does not exist on riscv32 for some reason.
+   Effectively:
+   s0 = open(argv[1], 0, 0644); */
+li a7, SYS_OPENAT
+li a0, AT_FDCWD
+lw a1, 8(sp)
+li a2, 0
+li a3, 0644
+ecall
+
+/* Error checking. This succeeds. */
+blt a0, zero, unrelated_error
+
+mv s0, a0
+
+/* The broken lseek() call.
+   Same also happens no matter the position in the file.
+   Effectively:
+   lseek(s0, 0, SEEK_CUR); */
+li a7, SYS_LSEEK
+mv a0, s0
+li a1, 0
+li a2, SEEK_CUR
+ecall
+
+/* XXX: lseek() returns -14 */
+blt a0, zero, lseek_error
+
+/* Close the file. */
+li a7, SYS_CLOSE
+mv a0, s0
+ecall
+
+/* Error checking. This also succeeds. */
+blt a0, zero, unrelated_error
+
+/* exit(0); */
+li a7, SYS_EXIT
+li a0, 0
+ecall
+
+/* exit(-return_value); */
+lseek_error:
+li a7, SYS_EXIT
+sub a0, zero, a0
+ecall
+
+unrelated_error:
+li a7, SYS_EXIT
+li a0, 128
+ecall
+```
+Steps to reproduce:
+1. riscv32-unknown-linux-gnu-as test.s -o test.o
+2. riscv32-unknown-linux-gnu-ld test.o
+3. qemu-riscv32 ./a.out test
+4. echo $? # This returns 14
+Additional information:
+Complete test setup:
+
+[test.tgz](/uploads/af68c9a5236628a9c6f31f2ce94e2f04/test.tgz)
diff --git a/results/classifier/zero-shot/108/files/888150 b/results/classifier/zero-shot/108/files/888150
new file mode 100644
index 000000000..e92deeb7f
--- /dev/null
+++ b/results/classifier/zero-shot/108/files/888150
@@ -0,0 +1,31 @@
+files: 0.922
+device: 0.839
+graphic: 0.791
+other: 0.752
+performance: 0.728
+network: 0.697
+semantic: 0.696
+vnc: 0.652
+permissions: 0.651
+debug: 0.637
+socket: 0.558
+PID: 0.461
+boot: 0.337
+KVM: 0.285
+
+qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions
+
+Hi guys, here I am, reporting yet another issue with qemu. This time, it's something that was first reported in January, and Juan proposed a patch for it:
+
+http://comments.gmane.org/gmane.comp.emulators.qemu/89009
+
+[PATCH 4/5] Reopen files after migration
+
+The symptom is, when running disk stress or any intense IO operation in guest while migrating it causes a qcow2 corruption. We've seen this consistently on the daily test jobs, both for qemu and qemu-kvm. The test that triggers it is autotest stress test running on a VM with ping-pong background migration.
+
+The fix proposed by Juan is on our RHEL branch and such a problem does not happen on the RHEL branch. So, what about re-considering Juan's patch, or maybe work out a solution that is satisfactory for the upstream maintainers?
+
+The URL that you've mentioned in the description is not valid anymore ... can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+