restructure results

author: Christian Krinitsin <mail@krinitsin.com> 2025-07-03 19:39:53 +0200
committer: Christian Krinitsin <mail@krinitsin.com> 2025-07-03 19:39:53 +0200
commit: dee4dcba78baf712cab403d47d9db319ab7f95d6 (patch)
tree: 418478faf06786701a56268672f73d6b0b4eb239 /results/classifier/zero-shot/118/files
parent: 4d9e26c0333abd39bdbd039dcdb30ed429c475ba (diff)
download: qemu-analysis-dee4dcba78baf712cab403d47d9db319ab7f95d6.tar.gz
qemu-analysis-dee4dcba78baf712cab403d47d9db319ab7f95d6.zip
70 files changed, 3977 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/files/1028 b/results/classifier/zero-shot/118/files/1028
new file mode 100644
index 000000000..511c8e063
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1028
@@ -0,0 +1,64 @@
+risc-v: 0.978
+files: 0.969
+TCG: 0.960
+debug: 0.938
+graphic: 0.934
+device: 0.911
+architecture: 0.910
+virtual: 0.900
+performance: 0.880
+VMM: 0.854
+peripherals: 0.850
+user-level: 0.847
+hypervisor: 0.828
+permissions: 0.782
+register: 0.770
+PID: 0.744
+semantic: 0.728
+ppc: 0.714
+socket: 0.694
+mistranslation: 0.683
+assembly: 0.654
+vnc: 0.621
+kernel: 0.585
+network: 0.560
+x86: 0.482
+arm: 0.471
+KVM: 0.420
+boot: 0.385
+i386: 0.205
+
+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/118/files/103 b/results/classifier/zero-shot/118/files/103
new file mode 100644
index 000000000..3326f3b88
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/103
@@ -0,0 +1,31 @@
+files: 0.860
+device: 0.736
+network: 0.730
+architecture: 0.682
+performance: 0.640
+register: 0.476
+arm: 0.416
+permissions: 0.368
+boot: 0.361
+PID: 0.348
+semantic: 0.328
+peripherals: 0.320
+socket: 0.299
+VMM: 0.299
+virtual: 0.288
+debug: 0.268
+ppc: 0.262
+risc-v: 0.243
+mistranslation: 0.241
+vnc: 0.205
+TCG: 0.182
+graphic: 0.129
+user-level: 0.113
+i386: 0.078
+hypervisor: 0.072
+kernel: 0.069
+assembly: 0.044
+x86: 0.036
+KVM: 0.009
+
+9pfs does not honor open file handles on unlinked files
diff --git a/results/classifier/zero-shot/118/files/1077806 b/results/classifier/zero-shot/118/files/1077806
new file mode 100644
index 000000000..581ccd937
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1077806
@@ -0,0 +1,38 @@
+files: 0.928
+mistranslation: 0.917
+virtual: 0.871
+device: 0.789
+user-level: 0.774
+architecture: 0.723
+boot: 0.714
+vnc: 0.710
+graphic: 0.700
+semantic: 0.625
+performance: 0.623
+PID: 0.613
+socket: 0.596
+risc-v: 0.538
+VMM: 0.532
+network: 0.530
+permissions: 0.526
+register: 0.499
+hypervisor: 0.490
+TCG: 0.444
+assembly: 0.423
+ppc: 0.416
+kernel: 0.415
+debug: 0.411
+arm: 0.367
+i386: 0.346
+x86: 0.340
+KVM: 0.238
+peripherals: 0.105
+
+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/118/files/1093360 b/results/classifier/zero-shot/118/files/1093360
new file mode 100644
index 000000000..862e09f7e
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1093360
@@ -0,0 +1,48 @@
+files: 0.957
+KVM: 0.904
+device: 0.847
+virtual: 0.775
+vnc: 0.763
+graphic: 0.726
+semantic: 0.691
+socket: 0.636
+hypervisor: 0.617
+mistranslation: 0.585
+network: 0.563
+register: 0.529
+boot: 0.525
+performance: 0.512
+architecture: 0.499
+VMM: 0.487
+permissions: 0.478
+ppc: 0.472
+debug: 0.469
+PID: 0.417
+user-level: 0.377
+arm: 0.366
+peripherals: 0.341
+assembly: 0.337
+risc-v: 0.331
+x86: 0.305
+kernel: 0.297
+i386: 0.278
+TCG: 0.248
+
+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/118/files/1098 b/results/classifier/zero-shot/118/files/1098
new file mode 100644
index 000000000..834018aa2
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1098
@@ -0,0 +1,41 @@
+files: 0.973
+graphic: 0.957
+device: 0.930
+x86: 0.845
+vnc: 0.836
+performance: 0.814
+PID: 0.771
+semantic: 0.719
+VMM: 0.664
+architecture: 0.627
+debug: 0.610
+permissions: 0.606
+ppc: 0.595
+virtual: 0.580
+socket: 0.560
+arm: 0.543
+risc-v: 0.511
+register: 0.458
+boot: 0.453
+TCG: 0.401
+network: 0.399
+mistranslation: 0.349
+i386: 0.269
+user-level: 0.243
+assembly: 0.092
+kernel: 0.089
+peripherals: 0.083
+hypervisor: 0.071
+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/118/files/1133668 b/results/classifier/zero-shot/118/files/1133668
new file mode 100644
index 000000000..d1c334d36
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1133668
@@ -0,0 +1,41 @@
+files: 0.869
+device: 0.805
+graphic: 0.793
+network: 0.647
+kernel: 0.594
+socket: 0.587
+semantic: 0.543
+vnc: 0.539
+user-level: 0.530
+mistranslation: 0.478
+performance: 0.476
+risc-v: 0.462
+architecture: 0.458
+TCG: 0.446
+VMM: 0.430
+ppc: 0.416
+register: 0.409
+PID: 0.386
+boot: 0.374
+arm: 0.349
+debug: 0.307
+peripherals: 0.280
+KVM: 0.231
+hypervisor: 0.204
+virtual: 0.128
+x86: 0.127
+i386: 0.111
+permissions: 0.110
+assembly: 0.012
+
+Bad validate ELF MIPSel format
+
+Detail and temporary path:
+
+http://www.devttys0.com/2011/12/qemu-vs-sstrip/#comment-10161
+
+To copy the information out of that web page for posterity:
+
+the problem is that we weren't able to execute ELF files in linux-user if they had had the section table stripped out of them. We fixed this in the way suggested in that web page, by simply not checking the section header size, since we don't care about the section headers when we load ELF files. This was fixed in commit d3606f07440ee2c2bebea2 in 2011.
+
+
diff --git a/results/classifier/zero-shot/118/files/1176 b/results/classifier/zero-shot/118/files/1176
new file mode 100644
index 000000000..365c97030
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1176
@@ -0,0 +1,37 @@
+files: 0.911
+graphic: 0.863
+device: 0.839
+network: 0.690
+vnc: 0.674
+architecture: 0.619
+ppc: 0.561
+socket: 0.494
+performance: 0.482
+risc-v: 0.442
+semantic: 0.403
+mistranslation: 0.362
+register: 0.346
+debug: 0.342
+VMM: 0.309
+boot: 0.293
+PID: 0.287
+virtual: 0.236
+hypervisor: 0.229
+arm: 0.214
+permissions: 0.202
+x86: 0.199
+TCG: 0.189
+peripherals: 0.189
+i386: 0.178
+kernel: 0.126
+user-level: 0.106
+assembly: 0.069
+KVM: 0.004
+
+VVFAT :rw writes from guest (ReactOS, windowsXP) not visible by host
+Description of problem:
+As described in https://jira.reactos.org/browse/CORE-18327
+While ./LMS is mounted as a :rw VVFAT drive, guest OS (ReactOS) is able to read files BUT when files are "written" from the guest, they are not visible on host side.
+QEMU execution is also massively polluted by "invalid file name" messages coming from https://git.qemu.org/?p=qemu.git;a=blob_plain;f=block/vvfat.c;hb=HEAD (but this is not specific to the use with ReactOS, as this is also observed with other guest : WXP, ...)
+
+See attached screenshot showing WXPSP3 as guest with file created in VVFAT drive while guest misses the newly created file.
diff --git a/results/classifier/zero-shot/118/files/1247478 b/results/classifier/zero-shot/118/files/1247478
new file mode 100644
index 000000000..d5255ebd4
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1247478
@@ -0,0 +1,64 @@
+files: 0.958
+graphic: 0.851
+device: 0.753
+performance: 0.733
+architecture: 0.683
+user-level: 0.673
+peripherals: 0.644
+semantic: 0.598
+ppc: 0.596
+network: 0.576
+assembly: 0.512
+socket: 0.504
+register: 0.481
+PID: 0.476
+debug: 0.469
+mistranslation: 0.417
+vnc: 0.344
+hypervisor: 0.333
+permissions: 0.325
+boot: 0.280
+x86: 0.278
+risc-v: 0.277
+virtual: 0.264
+VMM: 0.258
+TCG: 0.216
+arm: 0.213
+kernel: 0.195
+i386: 0.194
+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/118/files/1301 b/results/classifier/zero-shot/118/files/1301
new file mode 100644
index 000000000..1e883f52e
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1301
@@ -0,0 +1,47 @@
+files: 0.987
+graphic: 0.979
+vnc: 0.947
+boot: 0.942
+device: 0.925
+ppc: 0.921
+architecture: 0.872
+performance: 0.867
+permissions: 0.846
+peripherals: 0.832
+user-level: 0.789
+socket: 0.758
+register: 0.735
+kernel: 0.690
+debug: 0.679
+semantic: 0.649
+PID: 0.646
+network: 0.624
+arm: 0.605
+VMM: 0.603
+risc-v: 0.568
+virtual: 0.410
+mistranslation: 0.334
+hypervisor: 0.302
+assembly: 0.277
+TCG: 0.218
+x86: 0.148
+i386: 0.070
+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/118/files/1371915 b/results/classifier/zero-shot/118/files/1371915
new file mode 100644
index 000000000..4e825d586
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1371915
@@ -0,0 +1,78 @@
+files: 0.848
+graphic: 0.512
+architecture: 0.505
+permissions: 0.487
+performance: 0.487
+semantic: 0.484
+ppc: 0.417
+mistranslation: 0.408
+socket: 0.393
+device: 0.375
+x86: 0.357
+risc-v: 0.355
+PID: 0.355
+vnc: 0.346
+network: 0.339
+register: 0.337
+user-level: 0.332
+debug: 0.316
+hypervisor: 0.311
+virtual: 0.305
+kernel: 0.305
+boot: 0.292
+VMM: 0.286
+peripherals: 0.281
+i386: 0.252
+assembly: 0.233
+arm: 0.231
+TCG: 0.220
+KVM: 0.200
+
+Make Uninstall Rule Requested
+
+Environment: Ubuntu 14.04 - Qemu 2.1.1
+------------------
+I've configured qemu with some --prefix, compiled the sources and installed the binaries; now, for some reason, I need to uninstall qemu to configure it with the default prefix, recompile the sources and reinstall the binaries.
+However, there's no rule to uninstall qemu.
+
+All other packages which I have compiled and installed on my system offer the possibility to uninstall it: why not Qemu?
+
+just come to do the same...need to revert and cant :-(
+
+Can ubuntu 14.04 support the "checkinstall" program?
+If yes, then can we use the checkinstall program to fix this issue??
+
+Almost 5 years old. Please close this thread.
+
+Now we use meson for a build system, supporting "make uninstall" is potentially tractable, because meson itself supports 'uninstall' and we don't have a custom meson install script. We should check whether this is just a simple matter of wiring up the make target to meson and then do it, or else decide we don't want to support the feature...
+
+
+It already works since "make uninstall" is forwarded to "ninja uninstall" and from there to meson.
+
+This change is almost sufficient:
+
+diff --git a/Makefile b/Makefile
+index 76dbb917f5c..da01e3cd16a 100644
+--- a/Makefile
++++ b/Makefile
+@@ -156,7 +156,7 @@ NINJAFLAGS = $(if $V,-v) $(if $(MAKE.n), -n) $(if $(MAKE.k), -k0) \
+ ninja-cmd-goals = $(or $(MAKECMDGOALS), all)
+ ninja-cmd-goals += $(foreach t, $(.tests), $(.test.deps.$t))
+ 
+-makefile-targets := build.ninja ctags TAGS cscope dist clean uninstall
++makefile-targets := build.ninja ctags TAGS cscope dist clean
+ # "ninja -t targets" also lists all prerequisites.  If build system
+ # files are marked as PHONY, however, Make will always try to execute
+ # "ninja build.ninja".
+
+It makes "make uninstall" uninstall things; however it doesn't uninstall the various LC_MESSAGES files that meson installs, because those are installed by a "custom install script" that's part of the meson i18n module, and meson's uninstall functionality doesn't uninstall things installed that way. So it's a bit half-baked :-/
+
+
+
+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/109
+
+
diff --git a/results/classifier/zero-shot/118/files/1378407 b/results/classifier/zero-shot/118/files/1378407
new file mode 100644
index 000000000..8ca6d73a2
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1378407
@@ -0,0 +1,44 @@
+files: 0.885
+architecture: 0.876
+virtual: 0.803
+graphic: 0.706
+performance: 0.669
+mistranslation: 0.659
+boot: 0.649
+semantic: 0.638
+user-level: 0.565
+arm: 0.543
+device: 0.543
+permissions: 0.520
+register: 0.503
+PID: 0.465
+ppc: 0.422
+network: 0.400
+i386: 0.394
+vnc: 0.391
+kernel: 0.351
+debug: 0.336
+x86: 0.328
+risc-v: 0.301
+socket: 0.290
+assembly: 0.287
+VMM: 0.285
+hypervisor: 0.254
+TCG: 0.253
+peripherals: 0.230
+KVM: 0.126
+
+[feature request] Partition table wrapper for single-filesystem images
+
+Suppose you have a single filesystem image. It would be nice if QEMU could generate a virtual partition table for it and make it available to the guest as a partitioned disk. Otherwise you have to use workarounds like this: wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID
+
+It should be relatively easy to do on top of existing vvfat code.
+
+This is a rather specific use case.  Note that linux can use partitionless diskspace just fine, and depending on the bootmanager, one can use single partition as a virtual disk to boot linux too (syslinux supports this mode for one).  Implementing this feature in qemu does not make much sense to me, unless it is a generic block device remapper like dm in kernel, which is rather complex.  FWIW.
+
+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/118/files/1388 b/results/classifier/zero-shot/118/files/1388
new file mode 100644
index 000000000..81b6bb5f6
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1388
@@ -0,0 +1,44 @@
+files: 0.931
+x86: 0.884
+device: 0.772
+graphic: 0.708
+performance: 0.629
+architecture: 0.596
+network: 0.591
+mistranslation: 0.582
+semantic: 0.578
+socket: 0.558
+register: 0.506
+kernel: 0.491
+permissions: 0.488
+risc-v: 0.449
+ppc: 0.446
+VMM: 0.432
+PID: 0.431
+user-level: 0.424
+peripherals: 0.412
+vnc: 0.404
+boot: 0.396
+debug: 0.388
+arm: 0.357
+TCG: 0.288
+KVM: 0.287
+virtual: 0.274
+hypervisor: 0.262
+i386: 0.199
+assembly: 0.138
+
+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/118/files/1467 b/results/classifier/zero-shot/118/files/1467
new file mode 100644
index 000000000..77892ea3d
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1467
@@ -0,0 +1,31 @@
+files: 0.811
+ppc: 0.596
+VMM: 0.542
+vnc: 0.492
+TCG: 0.431
+device: 0.427
+network: 0.416
+risc-v: 0.416
+arm: 0.382
+virtual: 0.355
+KVM: 0.305
+boot: 0.292
+PID: 0.278
+i386: 0.252
+register: 0.219
+semantic: 0.195
+performance: 0.182
+peripherals: 0.180
+kernel: 0.130
+permissions: 0.128
+x86: 0.124
+graphic: 0.124
+socket: 0.114
+mistranslation: 0.112
+debug: 0.072
+architecture: 0.060
+hypervisor: 0.046
+user-level: 0.028
+assembly: 0.017
+
+guest agent file filtering
diff --git a/results/classifier/zero-shot/118/files/1469 b/results/classifier/zero-shot/118/files/1469
new file mode 100644
index 000000000..97a30c483
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1469
@@ -0,0 +1,78 @@
+files: 0.954
+semantic: 0.776
+vnc: 0.770
+debug: 0.766
+user-level: 0.756
+PID: 0.741
+ppc: 0.739
+device: 0.733
+risc-v: 0.660
+hypervisor: 0.657
+socket: 0.621
+graphic: 0.601
+KVM: 0.590
+architecture: 0.587
+assembly: 0.583
+network: 0.579
+kernel: 0.568
+arm: 0.487
+VMM: 0.472
+i386: 0.444
+x86: 0.440
+TCG: 0.407
+mistranslation: 0.405
+register: 0.390
+performance: 0.390
+boot: 0.375
+peripherals: 0.259
+permissions: 0.251
+virtual: 0.150
+
+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/118/files/1534978 b/results/classifier/zero-shot/118/files/1534978
new file mode 100644
index 000000000..a6fa9a475
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1534978
@@ -0,0 +1,56 @@
+files: 0.881
+boot: 0.868
+device: 0.777
+graphic: 0.680
+performance: 0.668
+socket: 0.629
+risc-v: 0.623
+semantic: 0.613
+kernel: 0.592
+permissions: 0.589
+vnc: 0.581
+network: 0.563
+ppc: 0.556
+i386: 0.542
+architecture: 0.529
+arm: 0.519
+VMM: 0.512
+mistranslation: 0.493
+peripherals: 0.471
+register: 0.467
+x86: 0.461
+PID: 0.457
+debug: 0.456
+hypervisor: 0.440
+user-level: 0.436
+KVM: 0.391
+TCG: 0.349
+virtual: 0.336
+assembly: 0.272
+
+Windows command line -name cannot use = sign
+
+Windows command line:
+
+qemu.exe -L . -name "32-bit Emulation Session RAM=500MB" -boot c -m 500 -drive file=\\.\PhysicalDrive2
+
+This fails to run.
+If I remove the = sign in the -name quoted string it runs OK.
+
+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.
+
+
+Cannot reproduce in recent version - please close.
+
+Thanks for checking! Closing now.
+
diff --git a/results/classifier/zero-shot/118/files/1561 b/results/classifier/zero-shot/118/files/1561
new file mode 100644
index 000000000..3e712bb7b
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1561
@@ -0,0 +1,57 @@
+files: 0.956
+semantic: 0.751
+graphic: 0.714
+PID: 0.545
+device: 0.542
+socket: 0.495
+performance: 0.481
+network: 0.471
+ppc: 0.449
+user-level: 0.398
+architecture: 0.388
+mistranslation: 0.378
+register: 0.362
+permissions: 0.341
+i386: 0.333
+arm: 0.329
+hypervisor: 0.329
+vnc: 0.327
+risc-v: 0.326
+x86: 0.315
+debug: 0.300
+kernel: 0.291
+VMM: 0.284
+peripherals: 0.280
+TCG: 0.258
+virtual: 0.244
+boot: 0.242
+KVM: 0.191
+assembly: 0.166
+
+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/118/files/1625 b/results/classifier/zero-shot/118/files/1625
new file mode 100644
index 000000000..e59392766
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1625
@@ -0,0 +1,43 @@
+files: 0.843
+graphic: 0.817
+device: 0.727
+performance: 0.606
+semantic: 0.586
+ppc: 0.507
+network: 0.465
+hypervisor: 0.431
+vnc: 0.402
+debug: 0.382
+risc-v: 0.377
+peripherals: 0.344
+PID: 0.329
+user-level: 0.314
+kernel: 0.299
+VMM: 0.280
+i386: 0.272
+socket: 0.271
+x86: 0.269
+architecture: 0.268
+arm: 0.261
+KVM: 0.259
+TCG: 0.246
+boot: 0.209
+mistranslation: 0.171
+permissions: 0.171
+register: 0.170
+virtual: 0.152
+assembly: 0.086
+
+[7.2.0] Qemu process hang with `defunct` when using `-blockdev` json property which file doesn't exists
+Description of problem:
+When using `throttle` and `throttle-group` to apply block device QOS,  
+there is something wrong with check file exists validation.  
+In upper commands, if the file which located `/mnt/b3b8dfb5-0a7c-4285-81d8-2bf8d33a3297/32c55f5a-96d1-4af4-a149-c95fd6652e3e/b016af76-f6b1-4614-b29a-78917924e55e` doesn't exist, it just hang with `defunct` process.  
+![defunct](/uploads/607c81f0c5a490a50cd0882139fded4b/defunct.png)
+Steps to reproduce:
+1. Start Guest with upper command.
+2. Hanged with defunct process
+3.
+Additional information:
+![1682511478](/uploads/4c6ec5d32e71bf5c116ed146a27dc8a6/1682511478.png)  
+- With GDB stack, i can find `no such file` error, but process don't exit
diff --git a/results/classifier/zero-shot/118/files/1653577 b/results/classifier/zero-shot/118/files/1653577
new file mode 100644
index 000000000..130d59ec5
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1653577
@@ -0,0 +1,39 @@
+files: 0.960
+permissions: 0.883
+device: 0.686
+graphic: 0.597
+architecture: 0.561
+mistranslation: 0.549
+network: 0.514
+semantic: 0.341
+i386: 0.320
+socket: 0.313
+ppc: 0.292
+peripherals: 0.253
+performance: 0.253
+register: 0.223
+x86: 0.194
+user-level: 0.192
+risc-v: 0.191
+assembly: 0.189
+boot: 0.178
+kernel: 0.161
+debug: 0.150
+hypervisor: 0.142
+vnc: 0.112
+arm: 0.106
+VMM: 0.105
+virtual: 0.105
+PID: 0.103
+TCG: 0.091
+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/118/files/1673957 b/results/classifier/zero-shot/118/files/1673957
new file mode 100644
index 000000000..a86a3d1a7
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1673957
@@ -0,0 +1,67 @@
+files: 0.986
+device: 0.984
+graphic: 0.983
+user-level: 0.963
+semantic: 0.957
+ppc: 0.953
+permissions: 0.947
+virtual: 0.946
+mistranslation: 0.944
+PID: 0.941
+performance: 0.933
+vnc: 0.923
+register: 0.921
+debug: 0.921
+architecture: 0.878
+socket: 0.855
+network: 0.843
+boot: 0.825
+arm: 0.821
+peripherals: 0.789
+risc-v: 0.771
+VMM: 0.769
+hypervisor: 0.758
+kernel: 0.752
+assembly: 0.740
+TCG: 0.701
+x86: 0.218
+i386: 0.197
+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/118/files/1685526 b/results/classifier/zero-shot/118/files/1685526
new file mode 100644
index 000000000..5df6f7990
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1685526
@@ -0,0 +1,48 @@
+files: 0.876
+virtual: 0.859
+device: 0.789
+mistranslation: 0.726
+semantic: 0.705
+network: 0.626
+register: 0.616
+vnc: 0.615
+architecture: 0.591
+peripherals: 0.550
+socket: 0.540
+kernel: 0.524
+boot: 0.523
+performance: 0.522
+permissions: 0.482
+PID: 0.452
+user-level: 0.439
+risc-v: 0.438
+graphic: 0.429
+debug: 0.398
+ppc: 0.384
+arm: 0.363
+VMM: 0.321
+hypervisor: 0.243
+TCG: 0.214
+x86: 0.201
+i386: 0.165
+KVM: 0.123
+assembly: 0.108
+
+UEFI firmware can't write to "fake" FAT hard disk
+
+Using the Tianocore OVMF UEFI firmware, a UEFI application cannot write to the emulated fat disk (-hda fat:rw:path/here). A file will get created or written, but will be corrupted.
+
+Looking through old bug tickets ... When reporting issues, please provide proper information on the versions that you were using (QEMU, OVMF, ...) and complete information about which command line parameters you used to start QEMU.
+
+Out of scope; please see my (independent, more recent) replies here:
+
+[edk2-devel] OVMF/QEMU shell based unit tests and writing to a virtual disk
+
+https://edk2.groups.io/g/devel/message/66655
+https://edk2.groups.io/g/devel/message/66656
+
+(alternative links:
+https://www.redhat.com/archives/edk2-devel-archive/2020-October/msg00877.html
+https://www.redhat.com/archives/edk2-devel-archive/2020-October/msg00878.html
+)
+
diff --git a/results/classifier/zero-shot/118/files/1720747 b/results/classifier/zero-shot/118/files/1720747
new file mode 100644
index 000000000..9fb99e153
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1720747
@@ -0,0 +1,38 @@
+files: 0.975
+mistranslation: 0.925
+device: 0.877
+performance: 0.800
+graphic: 0.768
+architecture: 0.768
+network: 0.768
+register: 0.753
+PID: 0.721
+kernel: 0.715
+vnc: 0.712
+risc-v: 0.710
+VMM: 0.663
+arm: 0.661
+socket: 0.648
+boot: 0.641
+TCG: 0.639
+ppc: 0.603
+KVM: 0.601
+permissions: 0.581
+semantic: 0.575
+hypervisor: 0.499
+peripherals: 0.498
+debug: 0.477
+i386: 0.463
+x86: 0.378
+user-level: 0.351
+assembly: 0.282
+virtual: 0.217
+
+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/118/files/1734 b/results/classifier/zero-shot/118/files/1734
new file mode 100644
index 000000000..5dcce7313
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1734
@@ -0,0 +1,46 @@
+files: 0.890
+arm: 0.880
+performance: 0.856
+device: 0.768
+architecture: 0.703
+graphic: 0.625
+kernel: 0.567
+semantic: 0.498
+PID: 0.483
+user-level: 0.479
+network: 0.470
+boot: 0.468
+register: 0.457
+risc-v: 0.448
+permissions: 0.447
+socket: 0.438
+vnc: 0.437
+VMM: 0.430
+peripherals: 0.399
+ppc: 0.382
+debug: 0.341
+hypervisor: 0.292
+mistranslation: 0.250
+virtual: 0.245
+TCG: 0.228
+assembly: 0.171
+KVM: 0.133
+i386: 0.112
+x86: 0.029
+
+mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version
+Description of problem:
+Trying to run an application using QEMU user mode for an ARM binary.  My host system is Ubuntu 22.04 based.  The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not.
+
+I created a repo with a readme, and a simple application that you can use to demonstrate the problem:
+https://github.com/mwales/qemu_mmap_test
+
+Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data.  Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted.
+Steps to reproduce:
+1. Compile test application that mmaps entire files
+2. Create 5 256MB test files
+3. Run the program tell it to mmap all the files.  The first 3 files succeed, but the 4th when run gets a -1 returned from mmap.
+Additional information:
+Lots of details on my github writeup and a demo of the bug in question.
+
+It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000).  I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that.  As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something.
diff --git a/results/classifier/zero-shot/118/files/1760262 b/results/classifier/zero-shot/118/files/1760262
new file mode 100644
index 000000000..b1d38ea5a
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1760262
@@ -0,0 +1,89 @@
+register: 0.964
+files: 0.940
+performance: 0.931
+semantic: 0.928
+ppc: 0.922
+graphic: 0.905
+architecture: 0.895
+i386: 0.893
+user-level: 0.893
+x86: 0.889
+peripherals: 0.887
+mistranslation: 0.876
+debug: 0.867
+hypervisor: 0.851
+permissions: 0.848
+risc-v: 0.845
+PID: 0.832
+arm: 0.814
+network: 0.810
+KVM: 0.805
+device: 0.799
+socket: 0.793
+assembly: 0.790
+virtual: 0.763
+VMM: 0.759
+kernel: 0.757
+TCG: 0.745
+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/118/files/1761153 b/results/classifier/zero-shot/118/files/1761153
new file mode 100644
index 000000000..62d97fac0
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1761153
@@ -0,0 +1,62 @@
+x86: 0.963
+i386: 0.958
+files: 0.949
+user-level: 0.933
+graphic: 0.912
+debug: 0.904
+architecture: 0.902
+network: 0.830
+arm: 0.825
+performance: 0.816
+mistranslation: 0.783
+semantic: 0.783
+device: 0.740
+kernel: 0.718
+PID: 0.716
+register: 0.681
+ppc: 0.663
+VMM: 0.649
+hypervisor: 0.647
+permissions: 0.641
+TCG: 0.633
+vnc: 0.609
+risc-v: 0.594
+peripherals: 0.577
+socket: 0.567
+virtual: 0.537
+boot: 0.517
+KVM: 0.503
+assembly: 0.473
+
+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/118/files/1788 b/results/classifier/zero-shot/118/files/1788
new file mode 100644
index 000000000..e119af42b
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1788
@@ -0,0 +1,59 @@
+files: 0.929
+arm: 0.924
+debug: 0.892
+performance: 0.891
+device: 0.884
+graphic: 0.868
+semantic: 0.861
+risc-v: 0.817
+TCG: 0.810
+ppc: 0.806
+network: 0.795
+vnc: 0.790
+VMM: 0.788
+permissions: 0.783
+register: 0.781
+user-level: 0.775
+hypervisor: 0.758
+assembly: 0.750
+PID: 0.745
+i386: 0.729
+boot: 0.728
+kernel: 0.727
+socket: 0.726
+KVM: 0.711
+x86: 0.711
+architecture: 0.691
+peripherals: 0.658
+virtual: 0.653
+mistranslation: 0.593
+
+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/118/files/1809 b/results/classifier/zero-shot/118/files/1809
new file mode 100644
index 000000000..32fd4b782
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1809
@@ -0,0 +1,83 @@
+architecture: 0.955
+files: 0.926
+performance: 0.922
+virtual: 0.901
+PID: 0.895
+device: 0.881
+socket: 0.875
+kernel: 0.828
+boot: 0.806
+register: 0.795
+peripherals: 0.774
+network: 0.762
+hypervisor: 0.759
+graphic: 0.755
+mistranslation: 0.742
+permissions: 0.708
+semantic: 0.696
+VMM: 0.689
+risc-v: 0.660
+arm: 0.657
+TCG: 0.626
+debug: 0.573
+user-level: 0.563
+ppc: 0.562
+vnc: 0.558
+assembly: 0.516
+x86: 0.496
+i386: 0.433
+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/118/files/1809304 b/results/classifier/zero-shot/118/files/1809304
new file mode 100644
index 000000000..2d4737f46
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1809304
@@ -0,0 +1,88 @@
+files: 0.957
+device: 0.938
+user-level: 0.909
+performance: 0.895
+graphic: 0.829
+semantic: 0.799
+VMM: 0.761
+PID: 0.750
+architecture: 0.745
+x86: 0.718
+risc-v: 0.715
+vnc: 0.708
+boot: 0.704
+ppc: 0.698
+virtual: 0.689
+register: 0.680
+network: 0.677
+i386: 0.667
+arm: 0.657
+socket: 0.650
+kernel: 0.648
+KVM: 0.641
+hypervisor: 0.627
+TCG: 0.590
+mistranslation: 0.572
+permissions: 0.564
+debug: 0.514
+peripherals: 0.467
+assembly: 0.432
+
+qemu-img convert is freezing for some DMG files.
+
+Recently, I created a file using hdiutil from MacOS (using Zlib compression):
+
+$ hdiutil create -volname MyVolName -srcfolder /path/to/my/vol/ -ov -format UDZO myvolname.dmg
+
+But, when I try to convert this volume using qemu-img convert, this command is freezing.
+
+I'm using the upstream version to test it.
+
+It is freezing inside the binary search method to retrieve the chunk.
+
+But, I still don't know why.
+
+I'm attaching the file as an example.
+
+It can be mounted using MacOS or other Linux apps like hfsleuth and darling-dmg.
+
+
+
+I have submitted a patch to prevent hanging in binary search.
+See: http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg05453.html?fbclid=IwAR0ObsaZ4kVMVv6MWIdq0ZCAN5tGhDsd9GmFv8_v7HBTl94Cu5EkRZ3z4n4
+
+Thanks,
+Yu-Chen Lin
+
+I'm almost sure that we need other improvements beyond fixing binary search deadlock.
+
+It is returning read errors when you apply your patch.
+
+Because of lacking zero chunk table, reading zero sector will return EIO.
+I have submitted a series to fix this problem.
+
+Please refer to this series: http://lists.nongnu.org/archive/html/qemu-devel/2018-12/msg05637.html
+
+Thanks,
+Yu-Chen Lin
+
+Hi Yu-Chen.
+
+The series looks good. It fixed the problems related to zero chunk. Nice work!
+
+I added a comment that I reviewed your patch considering my scenarios here. At least, It contributes to merge your changes.
+
+Additional info: tested with version 3.0.0. So, before pushing my commits. Conclusion: This is not a new bug.
+
+Since QEMU 4.0 has been released now, I assume we can close this ticket as "Fix released"? Or is there still anything left to do here?
+
+I re-test the dmg img with QEMU 4.0 again, and it works.
+
+In my opinion, the bug can be closed as "Fix released".
+
+Thanks.
+
+
+
+Thanks for testing. So I'm marking this now as "Fix released".
+
diff --git a/results/classifier/zero-shot/118/files/1809453 b/results/classifier/zero-shot/118/files/1809453
new file mode 100644
index 000000000..689d6f8b8
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1809453
@@ -0,0 +1,47 @@
+files: 0.873
+virtual: 0.804
+network: 0.762
+mistranslation: 0.662
+graphic: 0.594
+user-level: 0.573
+device: 0.543
+semantic: 0.528
+performance: 0.450
+socket: 0.318
+architecture: 0.286
+ppc: 0.248
+PID: 0.192
+x86: 0.190
+i386: 0.162
+register: 0.147
+boot: 0.123
+vnc: 0.123
+arm: 0.123
+risc-v: 0.107
+permissions: 0.089
+TCG: 0.078
+debug: 0.072
+VMM: 0.066
+peripherals: 0.059
+hypervisor: 0.009
+assembly: 0.005
+kernel: 0.005
+KVM: 0.004
+
+Windows  qemu download Big file bug in net user mode
+
+hi 
+
+Windows qemu with -net user downloading big files has a bug, -net tap is good!
+
+I suspect that the Slirp protocol has a bug on the Windows pc, which is normal on ubuntu.
+
+What is your version of qemu? I understand you are running qemu on ubuntu.
+
+The VM is windows? which version? Which URL are you downloading? What is the program being used?
+
+thanks
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/files/1810343 b/results/classifier/zero-shot/118/files/1810343
new file mode 100644
index 000000000..2f9862afd
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1810343
@@ -0,0 +1,51 @@
+files: 0.903
+device: 0.699
+network: 0.512
+performance: 0.387
+ppc: 0.366
+kernel: 0.357
+socket: 0.319
+semantic: 0.306
+PID: 0.290
+i386: 0.264
+mistranslation: 0.261
+vnc: 0.243
+graphic: 0.242
+x86: 0.212
+hypervisor: 0.202
+boot: 0.184
+architecture: 0.180
+register: 0.157
+permissions: 0.153
+user-level: 0.153
+peripherals: 0.151
+VMM: 0.143
+risc-v: 0.137
+KVM: 0.136
+TCG: 0.130
+virtual: 0.107
+assembly: 0.100
+debug: 0.093
+arm: 0.076
+
+qemu-nbd -l and -s options don't work together
+
+When using qemu-nbd with -l to load a snapshot along with -s to create new active layer the tool fails to find the snapshot specified on the command line:
+
+For example the following does not work:
+  sudo qemu-nbd -s --load-snapshot=files  --connect /dev/nbd0 rootfs.qcow2                                   
+  Failed to load snapshot: Can't find snapshot
+
+However, the following option works
+  sudo qemu-nbd -s --connect /dev/nbd0 rootfs.qcow2
+and so does
+  sudo qemu-nbd --load-snapshot=files  --connect /dev/nbd0 rootfs.qcow2
+
+
+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/159
+
+
diff --git a/results/classifier/zero-shot/118/files/1836453 b/results/classifier/zero-shot/118/files/1836453
new file mode 100644
index 000000000..41fb0c2a0
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1836453
@@ -0,0 +1,67 @@
+files: 0.973
+socket: 0.947
+architecture: 0.938
+network: 0.929
+device: 0.889
+user-level: 0.876
+PID: 0.875
+graphic: 0.856
+kernel: 0.855
+debug: 0.844
+permissions: 0.841
+semantic: 0.839
+hypervisor: 0.838
+vnc: 0.838
+ppc: 0.825
+VMM: 0.818
+performance: 0.811
+arm: 0.811
+peripherals: 0.809
+TCG: 0.721
+assembly: 0.718
+x86: 0.686
+mistranslation: 0.675
+register: 0.670
+KVM: 0.650
+boot: 0.622
+i386: 0.587
+risc-v: 0.584
+virtual: 0.556
+
+"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/118/files/1838703 b/results/classifier/zero-shot/118/files/1838703
new file mode 100644
index 000000000..58f308417
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1838703
@@ -0,0 +1,71 @@
+files: 0.889
+architecture: 0.881
+user-level: 0.786
+device: 0.758
+mistranslation: 0.746
+semantic: 0.730
+x86: 0.721
+ppc: 0.717
+register: 0.675
+arm: 0.634
+socket: 0.633
+PID: 0.618
+vnc: 0.575
+graphic: 0.548
+permissions: 0.515
+network: 0.515
+virtual: 0.507
+risc-v: 0.496
+boot: 0.491
+performance: 0.484
+VMM: 0.466
+hypervisor: 0.441
+i386: 0.434
+peripherals: 0.369
+kernel: 0.364
+debug: 0.329
+assembly: 0.306
+KVM: 0.276
+TCG: 0.243
+
+Makefile BUG in edk2 firmware install 4.1.0-rc3
+
+DESTDIR installs end up with wrong paths in JSON files installed to $prefix/share/qemu/firmware. For example, the file:
+
+  50-edk2-x86_64-secure.json
+
+ends up incorrectly with:
+
+  "filename": "/build/qemu/pkg/qemu/usr/share/qemu/edk2-x86_64-secure-code.fd",
+
+instead of the correct:
+
+  "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
+
+Related to commit 26ce90fde5c.
+
+What distribution/version are you using?
+
+I'm on Arch, but that shouldn't matter. It's a clear bug in the Makefile.
+
+I note that Fedora doesn't ship these blobs as they're provide by separate edk2 package. 
+
+Attached patch fixes it for me.
+
+The same issue was reported and patched on qemu-devel by Olaf Hering two months ago. The patch received three Reviewed-by tags, but nobody bothered to queue it.
+
+[Qemu-devel] [PATCH v1] Makefile: remove DESTDIR from firmware file cont
+
+The thread is split over two months, hence two links below, into the mailing list archive:
+https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07093.html
+https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg00690.html
+
+Patchew link:
+https://<email address hidden>/
+
+There shouldn't be a need to post a new patch, just for someone to pick up what's been posted already.
+
+Phil: "get_maintainer.pl" reports no official owners for the root Makefile, but you come out on top as commit-signer (26/70). Can you pick this one up, please? Thanks!
+
+Fixed in commit 177cd674d620 ("Makefile: remove DESTDIR from firmware file content", 2019-08-03), part of v4.1.0-rc4.
+
diff --git a/results/classifier/zero-shot/118/files/1858814 b/results/classifier/zero-shot/118/files/1858814
new file mode 100644
index 000000000..6c91ead8b
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1858814
@@ -0,0 +1,54 @@
+files: 0.828
+graphic: 0.815
+ppc: 0.674
+PID: 0.626
+device: 0.610
+register: 0.567
+semantic: 0.559
+architecture: 0.538
+mistranslation: 0.537
+user-level: 0.510
+arm: 0.506
+hypervisor: 0.505
+vnc: 0.495
+permissions: 0.490
+risc-v: 0.454
+debug: 0.449
+x86: 0.419
+network: 0.416
+peripherals: 0.416
+socket: 0.411
+i386: 0.409
+VMM: 0.406
+boot: 0.392
+kernel: 0.381
+performance: 0.373
+TCG: 0.369
+virtual: 0.364
+assembly: 0.319
+KVM: 0.303
+
+'make -C roms efi' does not update edk2 submodules
+
+On a fresh clone, 'make -C roms efi' fails because submodule is not initialized [1]:
+
+/builds/philmd/qemu/roms/edk2/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf(-1): error 000E: File/directory not found in workspace
+/builds/philmd/qemu/roms/edk2/CryptoPkg/Library/OpensslLib/openssl/e_os.h
+- Failed -
+
+Laszlo suggested [2] it is possibly a regression from commit f3e330e3c319:
+"roms/Makefile.edk2: don't pull in submodules when building from tarball"
+
+[1] https://gitlab.com/philmd/qemu/-/jobs/395644357#L436
+[2] https://<email address hidden>/msg668929.html
+
+Symptom persists as of v5.1.0, but I don't think it really matters. We should close the ticket as wontfix.
+
+There might be a big buildsys change in QEMU if we switch to Meson,
+so I'm waiting for that to happen first and then update this ticket.
+
+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/118/files/1877706 b/results/classifier/zero-shot/118/files/1877706
new file mode 100644
index 000000000..943bbd41d
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1877706
@@ -0,0 +1,81 @@
+architecture: 0.979
+x86: 0.943
+files: 0.937
+performance: 0.870
+ppc: 0.856
+semantic: 0.837
+user-level: 0.821
+device: 0.817
+graphic: 0.784
+vnc: 0.764
+boot: 0.760
+permissions: 0.759
+risc-v: 0.755
+network: 0.737
+PID: 0.736
+hypervisor: 0.729
+mistranslation: 0.714
+socket: 0.689
+register: 0.671
+virtual: 0.608
+kernel: 0.584
+VMM: 0.571
+assembly: 0.567
+debug: 0.563
+peripherals: 0.530
+TCG: 0.520
+i386: 0.513
+arm: 0.496
+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/118/files/1883414 b/results/classifier/zero-shot/118/files/1883414
new file mode 100644
index 000000000..80aa52cde
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1883414
@@ -0,0 +1,93 @@
+files: 0.970
+user-level: 0.953
+semantic: 0.892
+performance: 0.886
+graphic: 0.872
+mistranslation: 0.869
+vnc: 0.841
+architecture: 0.815
+KVM: 0.804
+debug: 0.784
+device: 0.749
+arm: 0.747
+register: 0.722
+PID: 0.709
+permissions: 0.709
+peripherals: 0.678
+hypervisor: 0.677
+x86: 0.674
+assembly: 0.669
+network: 0.669
+kernel: 0.662
+VMM: 0.622
+risc-v: 0.594
+boot: 0.587
+socket: 0.573
+TCG: 0.556
+virtual: 0.514
+ppc: 0.464
+i386: 0.464
+
+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/118/files/1885718 b/results/classifier/zero-shot/118/files/1885718
new file mode 100644
index 000000000..a5311bae1
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1885718
@@ -0,0 +1,97 @@
+files: 0.938
+ppc: 0.852
+socket: 0.848
+kernel: 0.843
+graphic: 0.816
+semantic: 0.802
+risc-v: 0.787
+PID: 0.776
+device: 0.776
+register: 0.746
+debug: 0.736
+arm: 0.687
+network: 0.681
+user-level: 0.667
+peripherals: 0.662
+mistranslation: 0.661
+VMM: 0.647
+vnc: 0.642
+permissions: 0.631
+performance: 0.614
+hypervisor: 0.597
+virtual: 0.591
+boot: 0.581
+KVM: 0.560
+x86: 0.531
+TCG: 0.530
+assembly: 0.495
+i386: 0.493
+architecture: 0.417
+
+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/118/files/1890775 b/results/classifier/zero-shot/118/files/1890775
new file mode 100644
index 000000000..d1fb1e5ee
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1890775
@@ -0,0 +1,87 @@
+files: 0.874
+peripherals: 0.869
+user-level: 0.855
+performance: 0.852
+virtual: 0.838
+device: 0.820
+graphic: 0.818
+mistranslation: 0.789
+architecture: 0.777
+semantic: 0.693
+network: 0.658
+permissions: 0.618
+hypervisor: 0.574
+socket: 0.573
+vnc: 0.535
+debug: 0.528
+register: 0.513
+kernel: 0.512
+ppc: 0.494
+risc-v: 0.436
+PID: 0.431
+VMM: 0.405
+assembly: 0.378
+boot: 0.348
+TCG: 0.329
+KVM: 0.316
+x86: 0.315
+i386: 0.282
+arm: 0.255
+
+Aten USB to Serial bridge does not work with qemu under Windows 10
+
+I would like to use MSDOS 6.22 with qemu (unfortunatelly lot of our test programs has been written in dos).
+I tried to connect two laptop by RS232 port, one of the machine have a built-in serial port and run with native MSDOS 6.22 with 4.0 norton commander. Another machine have only USB ports and i try to use a new Aten USB to Serial device. Ok. Has been started qemu with -serial and -chardev parameters, at startup appear a window with serial port setting such as baud rate, start bit, etc...
+
+Quemu has been satrted succeeded but serial port cannot be used becouse was nothing activited on usb serial adapter :(
+
+I tried same configuration with VirtualBox and everything was worked fine (serial connection was estabiled and copied several files from one machine into another machine), seems to be the emulated serial port has been worked fine.
+
+I would like to use qemu, i just thougt qemu is better, simple and faster...
+
+Exists solution or is this a qemu bug?
+
+Thank you!
+
+I forgot that the environment is Windows 10 64 bit.
+
+Hi again,
+
+Seems to be there is no solution for my problem :(
+I have succeeded create NTVDMx64 patch on my Windows 10 installation, so i can run directly 16 bit ms dos applications without any dos emulator.
+I take the initiative to close the bug.
+
+Bye
+
+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/118/files/1900 b/results/classifier/zero-shot/118/files/1900
new file mode 100644
index 000000000..6492bcda1
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1900
@@ -0,0 +1,31 @@
+files: 0.859
+semantic: 0.717
+device: 0.702
+vnc: 0.678
+performance: 0.674
+network: 0.671
+mistranslation: 0.663
+kernel: 0.648
+ppc: 0.639
+architecture: 0.601
+socket: 0.579
+VMM: 0.553
+graphic: 0.518
+debug: 0.513
+PID: 0.438
+TCG: 0.434
+arm: 0.378
+KVM: 0.358
+assembly: 0.358
+boot: 0.314
+register: 0.311
+risc-v: 0.295
+hypervisor: 0.271
+i386: 0.261
+x86: 0.245
+peripherals: 0.238
+permissions: 0.199
+virtual: 0.082
+user-level: 0.045
+
+8.1.0-r1: segfault at get_zones_wp() at ../block/file-posix.c:1337
diff --git a/results/classifier/zero-shot/118/files/1917 b/results/classifier/zero-shot/118/files/1917
new file mode 100644
index 000000000..c1b2e67c3
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1917
@@ -0,0 +1,81 @@
+files: 0.891
+architecture: 0.868
+graphic: 0.864
+network: 0.820
+user-level: 0.815
+ppc: 0.812
+permissions: 0.797
+virtual: 0.793
+semantic: 0.781
+assembly: 0.778
+socket: 0.764
+performance: 0.763
+hypervisor: 0.753
+PID: 0.749
+register: 0.748
+arm: 0.748
+boot: 0.732
+TCG: 0.726
+vnc: 0.724
+mistranslation: 0.722
+device: 0.722
+peripherals: 0.709
+risc-v: 0.708
+debug: 0.708
+KVM: 0.680
+VMM: 0.636
+kernel: 0.627
+x86: 0.599
+i386: 0.484
+
+cargo on ppc64 fails: invalid instruction: *EDIT*: on ntpdate as well
+Description of problem:
+Machine boots,
+but when compiling a rust library, the following issue appears:
+```
+cargo  build --release --manifest-path rust-src/Cargo.toml
+cargo[376]: illegal instruction (4) at 12e0933c0 nip 12e0933c0 lr 12dd7c768 code 1 in cargo[12dc10000+956000]
+cargo[376]: code: 00000000 00000000 00000000 7c0802a6 f8010010 f821ff11 fba100d8 60000000 
+cargo[376]: code: fbc100e0 8862cd50 28030000 418200d4 <104214c4> 38810070 3bc00000 7c4021ce 
+make: *** [Makefile:133: rust-src/target/release/libbcachefs_rust.a] Illegal instruction (core dumped)
+make: *** Waiting for unfinished jobs....
+ar[375]: illegal instruction (4) at 3fff9b2a4dac nip 3fff9b2a4dac lr 3fff9b2a4da4 code 1 in libLLVM-16.so.1[3fff99f10000+792f000]
+ar[375]: code: f87d0028 7fa3eb78 b29d0090 f89d0020 4810a8c1 60000000 7f83e378 7fa4eb78 
+ar[375]: code: 7fc5f378 49bfd3e1 e8410028 60000000 <104214c4> 38810070 fb610080 eba29fe0 
+make: *** [Makefile:129: libbcachefs.a] Illegal instruction (core dumped)
+make: *** Deleting file 'libbcachefs.a'
+```
+the core dump files of cargo and ar are attached
+
+~~I have no clue whether this is a rustc or qemu bug, so please let me know if this issue should be forwarded to rust devs~~
+EDIT: as this happens with ntpdate as well, I think it's an emulator issue:
+
+```
+ntpdig[1179]: illegal instruction (4) at 102382c4 nip 102382c4 lr 102382a8 code 1 in python3.11[10000000+63e000]
+ntpdig[1179]: code: 3d22ffdd c8094448 fc1e0000 41c2022c 4bde9b5d e8410028 3d42ffdd 39200000 
+ntpdig[1179]: code: c80a4450 91230000 fc1e0000 41c001a4 <ffe0f02c> fc1ff800 41c30280 3d22ffdd 
+```
+Steps to reproduce:
+1. create a debian ppc64 root image using debian sid & debootstrap
+2. install rust using rustup
+3. compile bcachefs-tools in ppc64
+
+2b. Install ntpdate using apt-get ntpdate
+3b. run ntpdate
+Additional information:
+Core dump command:
+```
+cat /proc/sys/kernel/core_pattern
+|/bin/cp --sparse=always /dev/stdin /host//repos/janpieter/linux/bcachefs/ktest-out/core.%e.PID%p.SIG%s.TIME%t
+```
+
+
+[core.ar.PID374.SIG4.TIME1696070088.xz](/uploads/6a540c4d13351871b1e22153ad87ab99/core.ar.PID374.SIG4.TIME1696070088.xz) AR core dump
+
+[core.ar.PID375.SIG4.TIME1696070088.xz](/uploads/7c314eba58c2190e3a9fbd88f8eb1242/core.ar.PID375.SIG4.TIME1696070088.xz) AR core dump
+
+[core.cargo.PID375.SIG4.TIME1696070087.xz](/uploads/0097d457eb2d25e0123874b59405647a/core.cargo.PID375.SIG4.TIME1696070087.xz) cargo core dump 
+
+[core.cargo.PID376.SIG4.TIME1696070087.xz](/uploads/53834fa9608036d6de9dafc3f778f165/core.cargo.PID376.SIG4.TIME1696070087.xz) cargo core dump
+
+[core.ntpdig.PID1171.SIG4.TIME1696070657.xz](/uploads/8a96d86338d7c6bebe39657a24f570d8/core.ntpdig.PID1171.SIG4.TIME1696070657.xz) ntpdig core dump
diff --git a/results/classifier/zero-shot/118/files/1917940 b/results/classifier/zero-shot/118/files/1917940
new file mode 100644
index 000000000..a743cbbad
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1917940
@@ -0,0 +1,68 @@
+architecture: 0.952
+x86: 0.951
+files: 0.935
+user-level: 0.907
+performance: 0.902
+semantic: 0.894
+device: 0.886
+boot: 0.848
+graphic: 0.822
+mistranslation: 0.752
+permissions: 0.742
+debug: 0.732
+hypervisor: 0.669
+peripherals: 0.651
+PID: 0.632
+assembly: 0.625
+register: 0.612
+network: 0.609
+ppc: 0.607
+arm: 0.601
+kernel: 0.577
+i386: 0.555
+risc-v: 0.513
+virtual: 0.512
+KVM: 0.509
+socket: 0.496
+TCG: 0.479
+VMM: 0.467
+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/118/files/1920211 b/results/classifier/zero-shot/118/files/1920211
new file mode 100644
index 000000000..3e235058d
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1920211
@@ -0,0 +1,76 @@
+files: 0.887
+performance: 0.878
+device: 0.815
+hypervisor: 0.739
+user-level: 0.731
+semantic: 0.728
+kernel: 0.714
+architecture: 0.712
+network: 0.702
+graphic: 0.683
+PID: 0.663
+permissions: 0.634
+register: 0.618
+i386: 0.608
+mistranslation: 0.598
+risc-v: 0.589
+x86: 0.586
+socket: 0.585
+arm: 0.582
+ppc: 0.556
+peripherals: 0.547
+vnc: 0.539
+debug: 0.515
+TCG: 0.502
+VMM: 0.499
+virtual: 0.495
+KVM: 0.483
+boot: 0.447
+assembly: 0.441
+
+shrink option for discard (for bad host-filesystems and -backup solutions)
+
+When using discard=unmap for virtio or scsi devices with QCOW2 images, space discarded by the guest will be unmaped on the host, which is basically great!
+
+This will turn the QCOW2 image into a sparse file which is efficient for most scenarios. But it may be that you need to avoid big sparse files on your host. For example because you need to use a backup solution which doesn't support sparse files well. Or maybe the QCOW2 image is on a filesystem mount which doesn't support sparse files at all.
+
+For those scenarios an alternative option for the discard setting (discard=shrink) would be great, so that the QCOW2 file itself gets shrunken again.
+I'm not sure about how the initial growing* of QCOW2 images is implemented and if there are maybe limitations. But I hope it may be possible do the inverse and actually shrink (not sparse) an QCOW2 image with internally discarded blocks.
+
+
+I'm using Qemu-5.2.0 and Linux >= 5.3 (host and guest).
+
+*If you use "qemu-img create -f qcow2 ..." withOUT the "preallocation" option.
+
+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/118/files/1939 b/results/classifier/zero-shot/118/files/1939
new file mode 100644
index 000000000..c2607b905
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1939
@@ -0,0 +1,94 @@
+files: 0.934
+hypervisor: 0.933
+performance: 0.922
+ppc: 0.917
+virtual: 0.898
+semantic: 0.891
+peripherals: 0.884
+architecture: 0.875
+mistranslation: 0.874
+PID: 0.845
+risc-v: 0.828
+device: 0.823
+debug: 0.809
+graphic: 0.778
+user-level: 0.774
+socket: 0.749
+arm: 0.734
+kernel: 0.732
+boot: 0.717
+permissions: 0.667
+assembly: 0.661
+network: 0.607
+KVM: 0.554
+vnc: 0.489
+VMM: 0.449
+register: 0.364
+x86: 0.276
+TCG: 0.212
+i386: 0.191
+
+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/118/files/1957 b/results/classifier/zero-shot/118/files/1957
new file mode 100644
index 000000000..5f3c0b76e
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/1957
@@ -0,0 +1,50 @@
+files: 0.876
+performance: 0.809
+network: 0.804
+graphic: 0.797
+kernel: 0.728
+device: 0.712
+boot: 0.689
+ppc: 0.644
+architecture: 0.643
+peripherals: 0.594
+semantic: 0.582
+hypervisor: 0.571
+permissions: 0.532
+vnc: 0.530
+socket: 0.510
+register: 0.500
+PID: 0.453
+arm: 0.427
+debug: 0.424
+risc-v: 0.424
+VMM: 0.418
+TCG: 0.396
+mistranslation: 0.350
+assembly: 0.305
+user-level: 0.302
+virtual: 0.270
+KVM: 0.245
+i386: 0.227
+x86: 0.200
+
+Reading files failed from QEMU TFTP server
+Description of problem:
+QEMU TFTP server on Linux is sensitive to the filename delimiters:
+
+After building QEMU UEFI firmware with the entire NetworkPkg stack and booting to UEFI shell, one can use `tftp` command to read files from the QEMU TFTP server specified during QEMU launching. i.e. `tftp 10.0.2.2 Boot\BCD`. However, when setting up the TFTP folder to be exactly the same (Linux and Windows), the result for running this command is different. On Windows host, this tftp command from emulated UEFI shell will proceed properly. But on Linux host, this will fail with "File Not Found".
+
+The issue seems to be around the slirp engine used by QEMU: the received packet will hand off to slirp as is, which leads to a host specific libc implementation of "open" function call: https://git.launchpad.net/ubuntu/+source/libslirp/tree/src/tftp.c#n113. Thus the server result would be different when the host is different.
+
+This will cause the PXE boot to fail when setting up the PXE folder on through QEMU on Linux because Windows will attempt to read BCD file at the same directory of the initial boot file, with a `\` in between.
+
+As TFTP protocol seems to be folder agnostic (just file names), in this case, should the TFTP server (QEMU here) handle the path normalization to make sure the file lookup to go through? Otherwise, Windows PXE boot on QEMU Linux host will always fail.
+
+Any suggestion here? Thanks in advance!
+Steps to reproduce:
+1. Build OVMF UEFI with full network stack
+2. Launch QEMU with the built UEFI with nic enabled, boot to UEFI shell.
+3. Invoke `tftp 10.0.2.2 Boot\BCD` from UEFI shell.
+4. When performing step 1-3 on Windows, this will succeed. But on Linux, this will fail with "File Not Found"
+Additional information:
+Attached is a wireshark dump from QEMU on Linux host. The same command sequence will all be successful on Windows host.
diff --git a/results/classifier/zero-shot/118/files/2029 b/results/classifier/zero-shot/118/files/2029
new file mode 100644
index 000000000..c00185a41
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2029
@@ -0,0 +1,31 @@
+files: 0.833
+performance: 0.803
+device: 0.751
+network: 0.634
+graphic: 0.539
+arm: 0.515
+debug: 0.494
+ppc: 0.462
+mistranslation: 0.415
+architecture: 0.403
+semantic: 0.354
+VMM: 0.331
+TCG: 0.310
+risc-v: 0.289
+kernel: 0.276
+PID: 0.265
+vnc: 0.259
+peripherals: 0.226
+i386: 0.213
+permissions: 0.181
+user-level: 0.173
+KVM: 0.170
+boot: 0.168
+hypervisor: 0.158
+x86: 0.154
+socket: 0.138
+virtual: 0.133
+register: 0.084
+assembly: 0.066
+
+[block jobs]Guest hang when dd file on snapshot overlay(iothread enable)
diff --git a/results/classifier/zero-shot/118/files/2117 b/results/classifier/zero-shot/118/files/2117
new file mode 100644
index 000000000..e0aebd9a8
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2117
@@ -0,0 +1,57 @@
+files: 0.923
+graphic: 0.775
+device: 0.763
+architecture: 0.671
+performance: 0.631
+semantic: 0.557
+hypervisor: 0.551
+PID: 0.548
+virtual: 0.489
+register: 0.440
+user-level: 0.425
+debug: 0.418
+assembly: 0.405
+peripherals: 0.399
+mistranslation: 0.378
+ppc: 0.374
+permissions: 0.364
+boot: 0.360
+vnc: 0.351
+socket: 0.344
+risc-v: 0.338
+i386: 0.271
+x86: 0.228
+arm: 0.227
+kernel: 0.213
+network: 0.201
+TCG: 0.156
+VMM: 0.119
+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/118/files/2205 b/results/classifier/zero-shot/118/files/2205
new file mode 100644
index 000000000..44f297169
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2205
@@ -0,0 +1,80 @@
+files: 0.939
+architecture: 0.837
+device: 0.831
+PID: 0.787
+user-level: 0.748
+graphic: 0.718
+mistranslation: 0.661
+socket: 0.656
+semantic: 0.605
+debug: 0.603
+x86: 0.581
+i386: 0.573
+performance: 0.554
+arm: 0.554
+network: 0.546
+vnc: 0.545
+permissions: 0.530
+ppc: 0.530
+register: 0.515
+kernel: 0.507
+TCG: 0.496
+risc-v: 0.449
+VMM: 0.431
+boot: 0.391
+assembly: 0.391
+virtual: 0.324
+hypervisor: 0.243
+peripherals: 0.173
+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/118/files/2238 b/results/classifier/zero-shot/118/files/2238
new file mode 100644
index 000000000..6293d8d71
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2238
@@ -0,0 +1,77 @@
+files: 0.921
+register: 0.919
+graphic: 0.878
+PID: 0.838
+performance: 0.832
+ppc: 0.816
+TCG: 0.775
+device: 0.770
+semantic: 0.766
+network: 0.766
+kernel: 0.759
+arm: 0.749
+socket: 0.747
+architecture: 0.746
+VMM: 0.709
+vnc: 0.692
+permissions: 0.675
+debug: 0.672
+peripherals: 0.670
+assembly: 0.654
+x86: 0.650
+i386: 0.636
+KVM: 0.627
+mistranslation: 0.621
+boot: 0.620
+risc-v: 0.595
+hypervisor: 0.568
+user-level: 0.502
+virtual: 0.466
+
+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/118/files/2422 b/results/classifier/zero-shot/118/files/2422
new file mode 100644
index 000000000..591bd4899
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2422
@@ -0,0 +1,99 @@
+risc-v: 0.980
+files: 0.974
+permissions: 0.945
+register: 0.940
+ppc: 0.933
+assembly: 0.932
+PID: 0.927
+graphic: 0.923
+kernel: 0.919
+performance: 0.908
+socket: 0.905
+user-level: 0.905
+device: 0.889
+architecture: 0.888
+arm: 0.883
+semantic: 0.871
+hypervisor: 0.857
+debug: 0.855
+mistranslation: 0.852
+network: 0.828
+virtual: 0.816
+boot: 0.801
+vnc: 0.783
+TCG: 0.709
+x86: 0.697
+VMM: 0.680
+i386: 0.666
+KVM: 0.642
+peripherals: 0.504
+
+`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/118/files/2466 b/results/classifier/zero-shot/118/files/2466
new file mode 100644
index 000000000..b3ebfdc37
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2466
@@ -0,0 +1,54 @@
+files: 0.894
+architecture: 0.824
+performance: 0.820
+graphic: 0.794
+semantic: 0.757
+register: 0.749
+assembly: 0.709
+device: 0.665
+user-level: 0.649
+vnc: 0.645
+hypervisor: 0.643
+debug: 0.637
+network: 0.592
+kernel: 0.547
+ppc: 0.538
+peripherals: 0.529
+x86: 0.511
+permissions: 0.493
+mistranslation: 0.473
+socket: 0.465
+KVM: 0.463
+boot: 0.459
+PID: 0.458
+arm: 0.454
+VMM: 0.451
+i386: 0.440
+risc-v: 0.416
+TCG: 0.401
+virtual: 0.343
+
+I'm not sure. But I Think I could cause the err(include/qemu/queue.h).
+Description of problem:
+At file "include/qemu/queue.h", Maybe I Think QTAILQ_REMOVE could cause a Error.
+
+```
+#define QTAILQ_REMOVE(head, elm, field) do {                            \
+       if (((elm)->field.tqe_next) != NULL)                            \
+           (elm)->field.tqe_next->field.tqe_circ.tql_prev =            \
+               (elm)->field.tqe_circ.tql_prev;                         \
+       else                                                            \
+           (head)->tqh_circ.tql_prev = (elm)->field.tqe_circ.tql_prev; \
+       (elm)->field.tqe_circ.tql_prev->tql_next = (elm)->field.tqe_next; \
+       (elm)->field.tqe_circ.tql_prev = NULL;                          \
+       (elm)->field.tqe_circ.tql_next = NULL;                          \
+       (elm)->field.tqe_next = NULL;                                   \
+} while (/*CONSTCOND*/0)
+```
+If the length of the que is one, line 7 cause a segmentation fault.
+Steps to reproduce:
+1. Create a Que with QTAILQ_INIT
+2. Add one element to que.
+3. Remove the element with QTAILQ_REMOVE
+Additional information:
+queue.h file is located at "inclue/qemu/queue.h"
diff --git a/results/classifier/zero-shot/118/files/2719 b/results/classifier/zero-shot/118/files/2719
new file mode 100644
index 000000000..c16d8ec03
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2719
@@ -0,0 +1,31 @@
+files: 0.841
+device: 0.655
+mistranslation: 0.567
+network: 0.551
+register: 0.527
+arm: 0.488
+risc-v: 0.482
+VMM: 0.453
+PID: 0.451
+vnc: 0.450
+socket: 0.442
+semantic: 0.412
+peripherals: 0.406
+TCG: 0.406
+performance: 0.387
+ppc: 0.368
+boot: 0.303
+architecture: 0.290
+permissions: 0.274
+kernel: 0.258
+virtual: 0.236
+debug: 0.218
+KVM: 0.210
+hypervisor: 0.203
+x86: 0.191
+user-level: 0.129
+graphic: 0.113
+i386: 0.112
+assembly: 0.079
+
+9.2.0 tarball contains unrelated files
diff --git a/results/classifier/zero-shot/118/files/2739 b/results/classifier/zero-shot/118/files/2739
new file mode 100644
index 000000000..95a479eeb
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2739
@@ -0,0 +1,33 @@
+files: 0.893
+boot: 0.854
+device: 0.823
+debug: 0.734
+graphic: 0.709
+architecture: 0.581
+kernel: 0.458
+semantic: 0.372
+mistranslation: 0.359
+arm: 0.356
+socket: 0.333
+register: 0.313
+performance: 0.275
+risc-v: 0.248
+vnc: 0.244
+permissions: 0.222
+virtual: 0.198
+PID: 0.188
+ppc: 0.177
+i386: 0.145
+network: 0.137
+x86: 0.113
+assembly: 0.077
+TCG: 0.061
+user-level: 0.059
+VMM: 0.059
+hypervisor: 0.022
+KVM: 0.020
+peripherals: 0.016
+
+Feature: Emulate GRUB2's initrd16 newc: feature for dynamic initrd generation
+Additional information:
+This feature is used in boot environments like WINPE, where GRUB2 leverages `initrd16` with `newc:` to load `wimboot` and then dynamically create an initrd containing necessary files for booting a Windows PE environment from a WIM image. Emulating this in QEMU would greatly improve the ability to test and debug such setups.
diff --git a/results/classifier/zero-shot/118/files/2761 b/results/classifier/zero-shot/118/files/2761
new file mode 100644
index 000000000..ac2e3e03c
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2761
@@ -0,0 +1,38 @@
+x86: 0.986
+files: 0.962
+architecture: 0.958
+virtual: 0.799
+graphic: 0.781
+device: 0.776
+arm: 0.720
+vnc: 0.553
+boot: 0.549
+semantic: 0.519
+ppc: 0.495
+debug: 0.481
+TCG: 0.456
+mistranslation: 0.418
+PID: 0.405
+VMM: 0.363
+risc-v: 0.363
+network: 0.343
+register: 0.313
+permissions: 0.249
+socket: 0.221
+kernel: 0.198
+performance: 0.184
+user-level: 0.159
+hypervisor: 0.087
+peripherals: 0.042
+KVM: 0.027
+i386: 0.014
+assembly: 0.008
+
+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/118/files/2786 b/results/classifier/zero-shot/118/files/2786
new file mode 100644
index 000000000..41c0c3c6b
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2786
@@ -0,0 +1,41 @@
+files: 0.995
+mistranslation: 0.925
+device: 0.868
+graphic: 0.814
+virtual: 0.647
+semantic: 0.628
+risc-v: 0.556
+performance: 0.500
+PID: 0.441
+arm: 0.337
+boot: 0.274
+architecture: 0.263
+ppc: 0.256
+assembly: 0.245
+debug: 0.220
+TCG: 0.203
+user-level: 0.121
+register: 0.120
+kernel: 0.113
+i386: 0.100
+vnc: 0.047
+VMM: 0.039
+permissions: 0.030
+peripherals: 0.023
+network: 0.021
+hypervisor: 0.010
+x86: 0.008
+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/118/files/2816 b/results/classifier/zero-shot/118/files/2816
new file mode 100644
index 000000000..154dc3522
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2816
@@ -0,0 +1,44 @@
+files: 0.994
+graphic: 0.889
+semantic: 0.822
+device: 0.787
+PID: 0.768
+kernel: 0.756
+debug: 0.712
+network: 0.658
+mistranslation: 0.628
+x86: 0.605
+socket: 0.603
+permissions: 0.601
+register: 0.596
+boot: 0.581
+vnc: 0.575
+architecture: 0.575
+i386: 0.569
+ppc: 0.563
+risc-v: 0.554
+user-level: 0.513
+VMM: 0.512
+performance: 0.505
+arm: 0.475
+TCG: 0.444
+hypervisor: 0.431
+virtual: 0.379
+peripherals: 0.301
+KVM: 0.293
+assembly: 0.212
+
+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/118/files/2825 b/results/classifier/zero-shot/118/files/2825
new file mode 100644
index 000000000..7c0ad1535
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2825
@@ -0,0 +1,67 @@
+architecture: 0.974
+x86: 0.968
+files: 0.949
+device: 0.945
+performance: 0.929
+graphic: 0.889
+permissions: 0.887
+kernel: 0.876
+i386: 0.872
+user-level: 0.866
+assembly: 0.847
+PID: 0.835
+arm: 0.771
+register: 0.764
+TCG: 0.756
+semantic: 0.746
+network: 0.742
+debug: 0.740
+ppc: 0.732
+hypervisor: 0.730
+peripherals: 0.722
+risc-v: 0.722
+mistranslation: 0.705
+VMM: 0.703
+socket: 0.696
+vnc: 0.668
+boot: 0.659
+KVM: 0.483
+virtual: 0.278
+
+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/118/files/2838 b/results/classifier/zero-shot/118/files/2838
new file mode 100644
index 000000000..c0933f052
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/2838
@@ -0,0 +1,38 @@
+files: 0.967
+device: 0.942
+graphic: 0.909
+network: 0.790
+vnc: 0.752
+socket: 0.708
+register: 0.706
+ppc: 0.651
+permissions: 0.636
+performance: 0.636
+debug: 0.617
+PID: 0.606
+boot: 0.584
+arm: 0.480
+architecture: 0.461
+semantic: 0.416
+risc-v: 0.411
+kernel: 0.298
+i386: 0.274
+user-level: 0.270
+TCG: 0.240
+mistranslation: 0.195
+x86: 0.186
+VMM: 0.154
+peripherals: 0.146
+hypervisor: 0.096
+virtual: 0.072
+assembly: 0.018
+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/118/files/408 b/results/classifier/zero-shot/118/files/408
new file mode 100644
index 000000000..75632a561
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/408
@@ -0,0 +1,31 @@
+files: 0.957
+architecture: 0.914
+device: 0.869
+network: 0.794
+arm: 0.706
+ppc: 0.689
+debug: 0.649
+VMM: 0.609
+socket: 0.602
+risc-v: 0.591
+TCG: 0.578
+semantic: 0.573
+performance: 0.538
+vnc: 0.522
+boot: 0.490
+PID: 0.440
+kernel: 0.387
+graphic: 0.342
+KVM: 0.335
+i386: 0.291
+mistranslation: 0.215
+register: 0.166
+permissions: 0.165
+peripherals: 0.136
+user-level: 0.112
+virtual: 0.094
+hypervisor: 0.085
+x86: 0.066
+assembly: 0.023
+
+DLLs not installing on 32bit version
diff --git a/results/classifier/zero-shot/118/files/459 b/results/classifier/zero-shot/118/files/459
new file mode 100644
index 000000000..561184a8f
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/459
@@ -0,0 +1,65 @@
+files: 0.944
+ppc: 0.900
+arm: 0.889
+kernel: 0.877
+PID: 0.876
+register: 0.868
+assembly: 0.840
+graphic: 0.796
+socket: 0.793
+architecture: 0.793
+peripherals: 0.783
+vnc: 0.767
+device: 0.758
+permissions: 0.755
+semantic: 0.754
+risc-v: 0.752
+user-level: 0.750
+performance: 0.740
+VMM: 0.687
+network: 0.649
+TCG: 0.648
+mistranslation: 0.591
+boot: 0.579
+hypervisor: 0.534
+KVM: 0.504
+debug: 0.497
+virtual: 0.308
+i386: 0.235
+x86: 0.156
+
+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/118/files/483 b/results/classifier/zero-shot/118/files/483
new file mode 100644
index 000000000..bbe5d65f1
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/483
@@ -0,0 +1,55 @@
+files: 0.912
+x86: 0.895
+graphic: 0.881
+network: 0.859
+performance: 0.856
+semantic: 0.850
+device: 0.840
+ppc: 0.829
+debug: 0.790
+architecture: 0.782
+hypervisor: 0.752
+kernel: 0.732
+socket: 0.720
+user-level: 0.706
+vnc: 0.706
+PID: 0.667
+register: 0.656
+permissions: 0.611
+i386: 0.599
+peripherals: 0.598
+assembly: 0.589
+VMM: 0.540
+arm: 0.536
+risc-v: 0.493
+mistranslation: 0.452
+TCG: 0.437
+KVM: 0.378
+boot: 0.332
+virtual: 0.283
+
+qemu doesn't process -object secret when read from a config file
+Description of problem:
+Qemu doesn't process -object secret lines when read from a config file.  This results in the new spice password-secret option failing with error: No secret with id '\<theid\>'
+Steps to reproduce:
+1. Create a password file
+```
+printf "password" > passfile.pw
+```
+2. Start qemu with command line options and also write to a config file
+```
+qemu-system-x86_64 \
+  -object secret,id=spicepwd,format=raw,file=passfile.pw \
+  -spice port=5901,password-secret=spicepwd \
+  -writeconfig qemu.cfg
+```
+3. Optional: Connect using spice client and password: "password"
+4. Exit qemu and cat qemu.cfg and verify it looks okay with equivalent options to what was specified on the command line
+5. Now attempt to start qemu and read the options using the config file
+```
+qemu-system-x86_64 -readconfig qemu.cfg
+```
+6. This fails with an error:
+```
+qemu-system-x86_64: No secret with id 'spicepwd'
+```
diff --git a/results/classifier/zero-shot/118/files/527 b/results/classifier/zero-shot/118/files/527
new file mode 100644
index 000000000..2f4c97f34
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/527
@@ -0,0 +1,31 @@
+files: 0.837
+device: 0.580
+semantic: 0.465
+arm: 0.409
+socket: 0.353
+mistranslation: 0.351
+permissions: 0.338
+PID: 0.316
+performance: 0.249
+kernel: 0.237
+register: 0.234
+VMM: 0.211
+risc-v: 0.210
+ppc: 0.194
+network: 0.193
+TCG: 0.193
+boot: 0.177
+architecture: 0.134
+vnc: 0.104
+x86: 0.097
+i386: 0.097
+user-level: 0.087
+KVM: 0.070
+virtual: 0.049
+debug: 0.041
+peripherals: 0.023
+hypervisor: 0.021
+graphic: 0.007
+assembly: 0.002
+
+Plain text files in docs/ should be converted to rst
diff --git a/results/classifier/zero-shot/118/files/562 b/results/classifier/zero-shot/118/files/562
new file mode 100644
index 000000000..0c096fd0a
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/562
@@ -0,0 +1,31 @@
+files: 0.961
+ppc: 0.875
+device: 0.791
+architecture: 0.763
+arm: 0.742
+graphic: 0.667
+network: 0.651
+kernel: 0.632
+socket: 0.625
+performance: 0.609
+mistranslation: 0.599
+vnc: 0.598
+permissions: 0.565
+TCG: 0.550
+VMM: 0.548
+debug: 0.533
+PID: 0.517
+KVM: 0.506
+register: 0.500
+boot: 0.451
+peripherals: 0.448
+risc-v: 0.443
+hypervisor: 0.440
+virtual: 0.426
+semantic: 0.420
+x86: 0.349
+i386: 0.309
+assembly: 0.239
+user-level: 0.172
+
+`ShaderTranslator.h` and `ShaderTranslator.cpp` files are missing and are not in ANGLE_ROOT/src/libShaderTranslator
diff --git a/results/classifier/zero-shot/118/files/640 b/results/classifier/zero-shot/118/files/640
new file mode 100644
index 000000000..6e1152061
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/640
@@ -0,0 +1,36 @@
+x86: 0.992
+architecture: 0.983
+files: 0.973
+graphic: 0.967
+device: 0.933
+debug: 0.892
+boot: 0.869
+performance: 0.810
+VMM: 0.662
+network: 0.649
+mistranslation: 0.647
+permissions: 0.626
+semantic: 0.608
+vnc: 0.582
+register: 0.569
+arm: 0.568
+PID: 0.534
+socket: 0.513
+kernel: 0.407
+TCG: 0.388
+ppc: 0.385
+user-level: 0.343
+i386: 0.301
+peripherals: 0.240
+risc-v: 0.229
+virtual: 0.088
+KVM: 0.037
+hypervisor: 0.036
+assembly: 0.032
+
+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/118/files/64322995 b/results/classifier/zero-shot/118/files/64322995
new file mode 100644
index 000000000..e49e4e636
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/64322995
@@ -0,0 +1,79 @@
+files: 0.941
+performance: 0.939
+mistranslation: 0.936
+device: 0.915
+network: 0.914
+semantic: 0.906
+graphic: 0.904
+kernel: 0.879
+ppc: 0.878
+PID: 0.875
+socket: 0.866
+register: 0.858
+user-level: 0.853
+debug: 0.837
+peripherals: 0.836
+permissions: 0.835
+hypervisor: 0.830
+architecture: 0.823
+vnc: 0.801
+VMM: 0.800
+risc-v: 0.799
+boot: 0.780
+TCG: 0.769
+x86: 0.760
+virtual: 0.748
+KVM: 0.742
+i386: 0.741
+arm: 0.728
+assembly: 0.653
+
+[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/118/files/705931 b/results/classifier/zero-shot/118/files/705931
new file mode 100644
index 000000000..31f248a2d
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/705931
@@ -0,0 +1,76 @@
+files: 0.912
+graphic: 0.852
+mistranslation: 0.833
+user-level: 0.829
+architecture: 0.824
+semantic: 0.724
+debug: 0.694
+device: 0.691
+performance: 0.689
+PID: 0.672
+permissions: 0.651
+assembly: 0.628
+peripherals: 0.616
+boot: 0.608
+risc-v: 0.598
+x86: 0.546
+kernel: 0.541
+ppc: 0.540
+arm: 0.533
+register: 0.503
+network: 0.444
+socket: 0.443
+TCG: 0.385
+i386: 0.383
+vnc: 0.378
+virtual: 0.366
+VMM: 0.353
+hypervisor: 0.335
+KVM: 0.188
+
+make ui sdl error 1 on git devel
+
+after clone git devel, try compile on slackware 13.1 32 bit machine got error:
+
+ui/sdl.c:809:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
+ui/sdl.c:815:36: error: expected ')' before '*' token
+/usr/include/X11/Xlib.h:3575:14: error: old-style parameter declarations in prototyped function definition
+/usr/include/X11/Xlib.h:3576:5: error: parameter name omitted
+ui/sdl.c:883:1: error: expected '{' at end of input
+ui/sdl.c:883:1: error: control reaches end of non-void function
+make: *** [ui/sdl.o] Error 1
+
+
+root@darkstar:/usr/src/qemu/qemu# gcc -v
+Reading specs from /usr/lib/gcc/i486-slackware-linux/4.5.1/specs
+COLLECT_GCC=gcc
+COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i486-slackware-linux/4.5.1/lto-wrapper
+Target: i486-slackware-linux
+Configured with: ../gcc-4.5.1/configure --prefix=/usr --libdir=/usr/lib --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=ada,c,c++,fortran,java,objc,lto --enable-threads=posix --enable-checking=release --with-system-zlib --with-python-dir=/lib/python2.6/site-packages --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-lto --with-gnu-ld --verbose --with-arch=i486 --target=i486-slackware-linux --build=i486-slackware-linux --host=i486-slackware-linux
+Thread model: posix
+gcc version 4.5.1 (GCC) 
+
+
+root@darkstar:/usr/src/qemu/qemu# uname -a
+Linux darkstar 2.6.35.7-smp #2 SMP Mon Oct 11 14:52:09 CDT 2010 i686 Intel(R) Core(TM)2 Duo CPU     T7100  @ 1.80GHz GenuineIntel GNU/Linux
+root@darkstar:/usr/src/qemu/qemu# cat /etc/slackware-version 
+Slackware 13.1.0
+
+thanks
+
+
+
+Hi,
+
+Thanks for reporting this issue. I'm not able to repeat the problem (although I have no slackware), and the bug does look strange.
+
+Can you update (git pull) and try again?
+
+Can you confirm that you are using git://git.qemu.org/qemu.git?
+
+If it still fails, can you look at the problem file (ui/sdl.c) and see if it looks complete? For me, this file has 895 lines (last line is blank, line 894 has the closing braces).
+
+qalbi, do you still have issues?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/zero-shot/118/files/708 b/results/classifier/zero-shot/118/files/708
new file mode 100644
index 000000000..e986830ac
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/708
@@ -0,0 +1,40 @@
+files: 0.981
+boot: 0.915
+device: 0.839
+graphic: 0.802
+kernel: 0.705
+semantic: 0.699
+debug: 0.616
+architecture: 0.534
+vnc: 0.524
+TCG: 0.464
+network: 0.458
+user-level: 0.446
+risc-v: 0.418
+PID: 0.399
+register: 0.354
+arm: 0.277
+socket: 0.266
+performance: 0.254
+ppc: 0.254
+VMM: 0.250
+mistranslation: 0.241
+hypervisor: 0.214
+i386: 0.183
+x86: 0.181
+peripherals: 0.170
+KVM: 0.161
+virtual: 0.155
+assembly: 0.113
+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/118/files/753 b/results/classifier/zero-shot/118/files/753
new file mode 100644
index 000000000..a1750c326
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/753
@@ -0,0 +1,31 @@
+files: 0.930
+performance: 0.898
+device: 0.891
+network: 0.701
+VMM: 0.597
+kernel: 0.553
+architecture: 0.548
+graphic: 0.545
+risc-v: 0.539
+debug: 0.535
+semantic: 0.517
+register: 0.512
+arm: 0.501
+vnc: 0.482
+TCG: 0.480
+boot: 0.451
+socket: 0.437
+ppc: 0.416
+permissions: 0.415
+PID: 0.400
+hypervisor: 0.283
+peripherals: 0.258
+x86: 0.181
+user-level: 0.159
+mistranslation: 0.153
+virtual: 0.142
+i386: 0.141
+assembly: 0.035
+KVM: 0.002
+
+qemu unable to convert file above 2 TB
diff --git a/results/classifier/zero-shot/118/files/823 b/results/classifier/zero-shot/118/files/823
new file mode 100644
index 000000000..7818a68a5
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/823
@@ -0,0 +1,51 @@
+files: 0.964
+graphic: 0.817
+device: 0.805
+PID: 0.765
+ppc: 0.762
+socket: 0.695
+semantic: 0.638
+register: 0.603
+performance: 0.511
+debug: 0.507
+network: 0.480
+vnc: 0.446
+permissions: 0.416
+arm: 0.278
+mistranslation: 0.268
+boot: 0.255
+TCG: 0.246
+user-level: 0.187
+x86: 0.166
+risc-v: 0.165
+KVM: 0.163
+architecture: 0.139
+i386: 0.122
+VMM: 0.114
+peripherals: 0.110
+virtual: 0.104
+hypervisor: 0.103
+kernel: 0.052
+assembly: 0.016
+
+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/118/files/836 b/results/classifier/zero-shot/118/files/836
new file mode 100644
index 000000000..3c2f92b88
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/836
@@ -0,0 +1,115 @@
+risc-v: 0.953
+files: 0.951
+performance: 0.948
+boot: 0.904
+graphic: 0.899
+device: 0.832
+architecture: 0.832
+kernel: 0.816
+PID: 0.809
+user-level: 0.793
+permissions: 0.762
+socket: 0.754
+x86: 0.743
+network: 0.731
+hypervisor: 0.730
+ppc: 0.721
+register: 0.714
+arm: 0.704
+debug: 0.697
+semantic: 0.638
+vnc: 0.624
+TCG: 0.624
+assembly: 0.613
+VMM: 0.611
+peripherals: 0.586
+i386: 0.580
+KVM: 0.552
+mistranslation: 0.520
+virtual: 0.330
+
+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/118/files/847 b/results/classifier/zero-shot/118/files/847
new file mode 100644
index 000000000..f73a9af43
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/847
@@ -0,0 +1,60 @@
+files: 0.912
+TCG: 0.869
+device: 0.851
+graphic: 0.838
+architecture: 0.793
+network: 0.765
+vnc: 0.748
+boot: 0.729
+peripherals: 0.716
+PID: 0.706
+kernel: 0.698
+ppc: 0.683
+socket: 0.654
+mistranslation: 0.628
+risc-v: 0.627
+semantic: 0.575
+arm: 0.566
+x86: 0.557
+performance: 0.546
+hypervisor: 0.514
+VMM: 0.503
+register: 0.487
+permissions: 0.458
+debug: 0.439
+i386: 0.349
+virtual: 0.296
+KVM: 0.172
+user-level: 0.168
+assembly: 0.151
+
+rdhpr %htstate unimplemented in translator
+Description of problem:
+I accidentally mixed up a copy of T1 and T2 sun4v firmwares and was able to trigger the following TCG assert ``tcg_reg_alloc_mov: Assertion `ts->val_type == TEMP_VAL_REG' failed.`` upon boot.
+
+Having discovered my mistake I was expecting the guest to crash at some point but without triggering an
+assert.
+Steps to reproduce:
+1. Download the attached file bug.tar.gz and extract it
+
+2. Apply the following diff to update the UART address for the T2 firmware
+
+```
+diff --git a/hw/sparc64/niagara.c b/hw/sparc64/niagara.c
+index ccad2c43a3..7af64bd50f 100644
+--- a/hw/sparc64/niagara.c
++++ b/hw/sparc64/niagara.c
+@@ -51,7 +51,7 @@ typedef struct NiagaraBoardState {
+ 
+ #define NIAGARA_PARTITION_RAM_BASE 0x80000000ULL
+ 
+-#define NIAGARA_UART_BASE   0x1f10000000ULL
++#define NIAGARA_UART_BASE   0xfff0c2c000ULL
+ 
+ #define NIAGARA_NVRAM_BASE  0x1f11000000ULL
+ #define NIAGARA_NVRAM_SIZE  0x2000
+```
+
+3. Run `./qemu-system-sparc64 -M niagara -L ./bug/ -m 256 -nographic`
+Additional information:
+
diff --git a/results/classifier/zero-shot/118/files/888150 b/results/classifier/zero-shot/118/files/888150
new file mode 100644
index 000000000..e7020f929
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/888150
@@ -0,0 +1,46 @@
+files: 0.922
+virtual: 0.859
+device: 0.839
+mistranslation: 0.797
+graphic: 0.791
+architecture: 0.766
+hypervisor: 0.741
+performance: 0.728
+network: 0.697
+semantic: 0.696
+vnc: 0.652
+permissions: 0.651
+peripherals: 0.642
+debug: 0.637
+ppc: 0.637
+kernel: 0.588
+x86: 0.559
+socket: 0.558
+VMM: 0.511
+user-level: 0.502
+register: 0.499
+TCG: 0.482
+PID: 0.461
+risc-v: 0.453
+arm: 0.437
+i386: 0.419
+assembly: 0.415
+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.]
+
diff --git a/results/classifier/zero-shot/118/files/913 b/results/classifier/zero-shot/118/files/913
new file mode 100644
index 000000000..fdd7531bb
--- /dev/null
+++ b/results/classifier/zero-shot/118/files/913
@@ -0,0 +1,31 @@
+files: 0.905
+device: 0.791
+network: 0.746
+risc-v: 0.524
+performance: 0.496
+arm: 0.485
+PID: 0.484
+register: 0.483
+architecture: 0.437
+semantic: 0.364
+boot: 0.360
+kernel: 0.344
+permissions: 0.330
+vnc: 0.328
+ppc: 0.272
+virtual: 0.269
+i386: 0.201
+graphic: 0.159
+socket: 0.149
+x86: 0.143
+hypervisor: 0.142
+TCG: 0.130
+assembly: 0.125
+VMM: 0.121
+debug: 0.109
+mistranslation: 0.104
+user-level: 0.044
+peripherals: 0.034
+KVM: 0.002
+
+QEMU Sharing Host files with Guest
author	Christian Krinitsin <mail@krinitsin.com>	2025-07-03 19:39:53 +0200
committer	Christian Krinitsin <mail@krinitsin.com>	2025-07-03 19:39:53 +0200
commit	dee4dcba78baf712cab403d47d9db319ab7f95d6 (patch)
tree	418478faf06786701a56268672f73d6b0b4eb239 /results/classifier/zero-shot/118/files
parent	4d9e26c0333abd39bdbd039dcdb30ed429c475ba (diff)
download	qemu-analysis-dee4dcba78baf712cab403d47d9db319ab7f95d6.tar.gz qemu-analysis-dee4dcba78baf712cab403d47d9db319ab7f95d6.zip