17 files changed, 533 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/files/181 b/results/classifier/gemma3:12b/files/181
new file mode 100644
index 000000000..11f1f2834
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/181
@@ -0,0 +1,2 @@
+
+qemu crashes when doing iotest on  virtio-9p filesystem
diff --git a/results/classifier/gemma3:12b/files/1810343 b/results/classifier/gemma3:12b/files/1810343
new file mode 100644
index 000000000..78090febc
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1810343
@@ -0,0 +1,13 @@
+
+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
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1810405 b/results/classifier/gemma3:12b/files/1810405
new file mode 100644
index 000000000..dcc172680
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1810405
@@ -0,0 +1,23 @@
+
+source tarball has errors when untarring
+
+If you download qemu-2.10.0.tar.xv and/or qemu-2.10.1.tar.xv, and follow the directions at https://www.qemu.org/download/, you get a tar error.
+
+
+To repro:
+$ wget  https://download.qemu.org/qemu-2.10.0.tar.xz
+$ tar  xJf qemu-2.10.0.tar.xz 
+tar: qemu-2.10.0/roms/u-boot/scripts/Kconfig: Cannot open: File exists
+tar: Exiting with failure status due to previous errors
+
+$ tar --version
+tar (GNU tar) 1.29
+Copyright (C) 2015 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+
+Written by John Gilmore and Jay Fenlason.
+
+
+Apologies if I'm being an idiot here.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1810433 b/results/classifier/gemma3:12b/files/1810433
new file mode 100644
index 000000000..29912e5d0
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1810433
@@ -0,0 +1,48 @@
+
+aarch64-linux-user master: inconsistent pwrite behaviour
+
+Hello,
+
+I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90
+
+And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0.
+Minimal reproducible sample is the following:
+
+#define _GNU_SOURCE
+#include <stdlib.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <string.h>
+
+/*
+ System                  | Result
+-------------------------+----------------
+ Native x86_64 4.12.14   | pwrite ret = 0
+ Native aarch64 4.4.159  | pwrite ret = 0
+ qemu-aarch64 at x86_64  | pwrite ret = -1
+   ( 20d6c7312f1b8 )     |
+*/
+
+int main(int argc, char** argv) {
+	int fd = open("test.dat", O_CREAT | O_RDWR, 0644);
+	if (fd < 0) {
+		perror("open");
+		return 1;
+	}
+
+	int ret = fallocate(fd, 0, 0, 1000);
+	if (ret < 0) {
+		perror("fallocate");
+		return 1;
+	}
+
+	ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0);
+	printf("pwrite ret = %ld\n", ret_pwrite);
+
+	close(fd);
+
+	return 0;
+}
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1810590 b/results/classifier/gemma3:12b/files/1810590
new file mode 100644
index 000000000..4e3e40e1f
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1810590
@@ -0,0 +1,22 @@
+
+Record/replay example does not work
+
+Trying the record part of the record/replay example at https://github.com/qemu/qemu/blob/master/docs/replay.txt qemu immediately hangs with no guest output displayed.  This is with qemu from today's git (e59dbbac0364344a3ad84c3497a98c56003d3fb8).
+
+To reproduce:
+
+  wget https://people.debian.org/~aurel32/qemu/i386/debian_squeeze_i386_standard.qcow2
+
+  mv debian_squeeze_i386_standard.qcow2 disk.qcow2
+
+  qemu-system-i386 \
+       -icount shift=7,rr=record,rrfile=replay.bin \
+       -drive file=disk.qcow2,if=none,id=img-direct \
+       -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
+       -device ide-hd,drive=img-blkreplay \
+       -netdev user,id=net1 -device rtl8139,netdev=net1 \
+       -object filter-replay,id=replay,netdev=net1
+
+The above qemu command line is exactly the same as in the example.
+
+Tested on a Debian 9 x86_64 host.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1811711 b/results/classifier/gemma3:12b/files/1811711
new file mode 100644
index 000000000..0434249b5
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1811711
@@ -0,0 +1,72 @@
+
+qemu-img can not convert virtualbox virtual disk formats qcow
+
+Hello, I'm working with QEMU on macOS, and am experiencing issues working with the `qemu-img` command.
+
+Info
+----
+$ sw_vers
+ProductName:    Mac OS X
+ProductVersion: 10.13.6
+BuildVersion:   17G4015
+
+VirtualBox
+----------
+$ VBoxManage --version
+6.0.0r127566
+
+$ qemu-system-x86_64 --version
+QEMU emulator version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty)
+Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
+
+$ qemu-img --version
+qemu-img version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty)
+Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
+
+Steps to reproduce
+------------------
+
+> Prereq VirtualBox needs to be installed to run the `VBoxManage` command
+
+$ VBoxManage createmedium disk --filename vbox-vdisk-exp.qcow --format qcow --size 5
+0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
+Medium created. UUID: e2b36955-3791-4c0e-93d4-913669b1d9fb
+
+$ file vbox-vdisk-exp.qcow
+vbox-vdisk-exp.qcow: QEMU QCOW Image (v1), 5242880 bytes
+
+$ qemu-img info vbox-vdisk-exp.qcow
+image: vbox-vdisk-exp.qcow
+file format: qcow
+virtual size: 5.0M (5242880 bytes)
+disk size: 8.0K
+cluster_size: 4096
+
+# Convert vbox virtualdisk to qcow2 format using `qemu-img`
+$ qemu-img convert -f qcow vbox-vdisk-exp.qcow -O qcow2 vbox-vdisk-exp-convert.qcow2
+
+$ file vbox-vdisk-exp-convert.qcow2
+vbox-vdisk-exp-convert.qcow2: QEMU QCOW Image (v3), 5242880 bytes
+
+# Print info about qemu-img converted image from vbox created qcow image
+$ qemu-img info vbox-vdisk-exp-convert.qcow2                                                   mutts-6 | 0 < 10:53:00
+image: vbox-vdisk-exp-convert.qcow2
+file format: qcow2
+virtual size: 5.0M (5242880 bytes)
+disk size: 196K
+cluster_size: 65536
+Format specific information:
+    compat: 1.1
+    lazy refcounts: false
+    refcount bits: 16
+    corrupt: false
+
+# Print info about vbox created qcow image
+qemu-img info vbox-vdisk-exp.qcow                                                            mutts-6 | 0 < 10:53:19
+image: vbox-vdisk-exp.qcow
+file format: qcow
+virtual size: 5.0M (5242880 bytes)
+disk size: 8.0K
+cluster_size: 4096
+
+I've attached a zip file containing the vbox created qcow image along with the image that `qemu-img` converted.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1813307 b/results/classifier/gemma3:12b/files/1813307
new file mode 100644
index 000000000..ead96217c
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1813307
@@ -0,0 +1,22 @@
+
+util/path.c/follow_path() does not handle "/" well
+
+Hello,
+
+I noticed that qemu does not handle "/" very well in follow_path().
+
+Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd.
+
+Indeed it does something like
+  if (__lstat ("/", &st) < 0)
+.....
+and then loops from current dir toward the top using lstat("..")
+
+On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot).
+OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails.
+
+I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so?
+
+If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ?
+
+Thanks
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1813406 b/results/classifier/gemma3:12b/files/1813406
new file mode 100644
index 000000000..9d96d7309
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1813406
@@ -0,0 +1,8 @@
+
+qemu-img convert malfunction on macOS
+
+On macOS 10.13.6, `qemu-img convert` failed to convert a qcow2 into a new qcow2 (for the purpose of shrinking the image).
+
+A 50GB (3.7GB allocated) qcow2 image was used as source. The qemu-img convert output was a 3.4MB file. 
+
+qemu-img from HomeBrew were tested. Both 2.11.1 and 3.1.0_1 failed to convert a qcow2 image.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1814418 b/results/classifier/gemma3:12b/files/1814418
new file mode 100644
index 000000000..5de0c422a
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1814418
@@ -0,0 +1,22 @@
+
+persistent bitmap will be inconsistent when qemu  crash, 
+
+Follow these steps to reappear the bug:
+
+1. start qemu
+2. add persistent bitmap: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}'
+3. kill -9 qemu (simulate Host crash, eg. lose power)
+4. restart qemu
+
+Now, the '{ "execute": "query-block" }' can't find the bitmap0. I can understand at this point, because the bitmap0 has not been synchronized yet.
+
+But, when I try to add persistent bitmap0 again: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}', It failed:
+
+{"id":"libvirt-42","error":{"class":"GenericError","desc":"Can't make bitmap 'bitmap0' persistent in 'drive-virtio-disk1': Bitmap with the same name is already stored"}}
+
+In other word, when qemu crash, the qcow2 image remain the incomplete persistent bitmap.
+
+---
+
+qemu version: 2.12.0 and 3.1.0, other version I does not test yet.
+qemu command: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1814420 b/results/classifier/gemma3:12b/files/1814420
new file mode 100644
index 000000000..0070ffe1d
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1814420
@@ -0,0 +1,28 @@
+
+drive-backup with iscsi, it will failed "Could not create image: Invalid argument"
+
+I use iscsi protocol to drive-backup:
+
+---iscsi target---
+yum -y install targetcli python-rtslib
+systemctl start target
+systemctl enable target
+targetcli /iscsi create iqn.2019-01.com.iaas
+targetcli /iscsi/iqn.2019-01.com.iaas/tpg1 set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1
+targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/portals create 192.168.1.1 3260
+targetcli /backstores/fileio create file1 /opt/file1 2G
+targetcli /iscsi/iqn.2019-01.com.iaas/tpg1/luns create /backstores/fileio/file1
+-------------------
+
+Now, '{ "execute" : "drive-backup" , "arguments" : { "device" : "drive-virtio-disk0" , "sync" : "top" , "target" : "iscsi://192.168.1.1:3260/iqn.2019-01.com.iaas/0" } }'
+
+It may failed: {"id":"libvirt-1785","error":{"class":"GenericError","desc":"Could not create image: Invalid argument"}}
+
+But, This abnormal will be appear at the first time. Because when I retry again, It works very well.
+
+Then, I re-start the vm, It still be failed 'Could not create image: Invalid argument' on the first try, and the second try it will work very well.
+
+---
+Host: centos 7.5
+qemu version: 2.12 and 3.1.0
+qemu command line: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1815252 b/results/classifier/gemma3:12b/files/1815252
new file mode 100644
index 000000000..3be0dedc6
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1815252
@@ -0,0 +1,65 @@
+
+virtio-9p-pci passthrough fsync hang
+
+Tested against QEMU: e47f81b617684c4546af286d307b69014a83538a
+
+and $qemu-system-x86_64 --version
+QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
++ exec sudo qemu-system-x86_64 -enable-kvm -bios /usr/share/ovmf/OVMF.fd -cpu host -smp sockets=1,cpus=4,cores=2 -m 2048 -vga none -nographic -chardev socket,id=chrtpm0,path=/tmp/clrwifi/swtpm2/tpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm0 -device tpm-tis,tpmdev=tpm0 -device virtio-rng-pci -netdev user,id=mynet0,hostfwd=tcp::10022-:22 -device virtio-net-pci,netdev=mynet0 -kernel /home/.../Documents/c/iwd/tools/bzImage -append 'console=ttyS0,115200n8 quiet kvm-intel.nested=1 init=/usr/bin/bash initcall_debug tsc=reliable no_timer_check noreplace-smp cryptomgr.notests rootfstype=9p root=/dev/root rootflags=trans=virtio,version=9p2000.u rw' -fsdev local,id=fsdev-root,path=mnt,security_model=passthrough -device virtio-9p-pci,fsdev=fsdev-root,mount_tag=/dev/root
+[    0.000000] Linux version 4.19.0-rc2 (...) (gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)) #10 SMP Fri Feb 8 13:55:20 PST 2019
+[    0.000000] Command line: console=ttyS0,115200n8 quiet kvm-intel.nested=1 init=/usr/bin/bash initcall_debug tsc=reliable no_timer_check noreplace-smp cryptomgr.notests rootfstype=9p root=/dev/root rootflags=trans=virtio,version=9p2000.u rw
+[    0.000000] KERNEL supported cpus:
+[    0.000000]   Intel GenuineIntel
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
+[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
+[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
+[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
+[    0.000000] BIOS-provided physical RAM map:
+[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000007fffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000800000-0x0000000000807fff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000808000-0x000000000080ffff] usable
+[    0.000000] BIOS-e820: [mem 0x0000000000810000-0x00000000008fffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x0000000000900000-0x000000007e87efff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007e87f000-0x000000007e888fff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000007e889000-0x000000007e889fff] ACPI data
+[    0.000000] BIOS-e820: [mem 0x000000007e88a000-0x000000007e88bfff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007e88c000-0x000000007e88ffff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000007e890000-0x000000007e8a9fff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007e8aa000-0x000000007e8b9fff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000007e8ba000-0x000000007e8bafff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007e8bb000-0x000000007e9e5fff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007e9e6000-0x000000007e9edfff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000007e9ee000-0x000000007eb1afff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007eb1b000-0x000000007fb9afff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007fb9b000-0x000000007fbf2fff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007fbf3000-0x000000007fbfafff] ACPI data
+[    0.000000] BIOS-e820: [mem 0x000000007fbfb000-0x000000007fbfefff] ACPI NVS
+[    0.000000] BIOS-e820: [mem 0x000000007fbff000-0x000000007ff3ffff] usable
+[    0.000000] BIOS-e820: [mem 0x000000007ff40000-0x000000007ff5ffff] reserved
+[    0.000000] BIOS-e820: [mem 0x000000007ff60000-0x000000007fffffff] ACPI NVS
+[    0.352469] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed
+Started bpfilter
+bash: cannot set terminal process group (-1): Inappropriate ioctl for device
+bash: no job control in this shell
+grep: /proc/cpuinfo: No such file or directory
+grep: /proc/cpuinfo: No such file or directory
+root@clr / # passwd
+...
+openat(AT_FDCWD, "/etc/nshadow", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
+umask(077)                              = 077
+openat(AT_FDCWD, "/etc/shadow", O_RDONLY|O_CREAT|O_CLOEXEC, 000) = 5
+fcntl(5, F_GETFL)                       = 0x8000 (flags O_RDONLY|O_LARGEFILE)
+fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
+fchown(4, 0, 0)                         = 0
+fchmod(4, 0100644)                      = 0
+lseek(5, 0, SEEK_CUR)                   = 0
+fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
+read(5, "", 8192)                       = 0
+close(5)                                = 0
+fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
+write(4, "root:$6$jihvB1NonG88C5Yt$kvDCqF7"..., 124) = 124
+fsync(4 <- hung here
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1817 b/results/classifier/gemma3:12b/files/1817
new file mode 100644
index 000000000..f1d81e926
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1817
@@ -0,0 +1,2 @@
+
+meson complains about use of install_subdir in docs/meson.build
diff --git a/results/classifier/gemma3:12b/files/1817345 b/results/classifier/gemma3:12b/files/1817345
new file mode 100644
index 000000000..ee5a11200
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1817345
@@ -0,0 +1,42 @@
+
+configure script breaks when $source_path contains white spaces
+
+Hi,
+
+I noticed that the configure script breaks when the qemu source directory is in a path containing white spaces, in particular the list of targets is not correctly generated when calling "./configure --help".
+
+Steps to reproduce the problem:
+
+$ mkdir "dir with spaces"
+$ cd dir\ with\ spaces/
+$ git clone https://git.qemu.org/git/qemu.git
+$ cd qemu/
+$ ./configure --help | grep -A3 target-list
+
+
+Actual result:
+
+  --target-list=LIST       set target list (default: build everything)
+                           Available targets: dir with *-softmmu dir with 
+                           *-linux-user
+
+
+Expected result:
+
+  --target-list=LIST       set target list (default: build everything)
+                           Available targets: aarch64-softmmu alpha-softmmu 
+                           arm-softmmu cris-softmmu hppa-softmmu i386-softmmu 
+                           lm32-softmmu m68k-softmmu microblaze-softmmu 
+
+
+This happens because the $mak_wilds variable uses spaces to separate different paths, maybe newlines may be used, which are less likely to be in directory names.
+
+BTW "shellcheck" may help finding some other problems.
+
+Qemu version:
+
+$ git describe 
+v3.1.0-1960-ga05838cb2a
+
+Thanks,
+   Antonio
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1818122 b/results/classifier/gemma3:12b/files/1818122
new file mode 100644
index 000000000..7aa042d0f
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1818122
@@ -0,0 +1,89 @@
+
+QEMU 3.1 makes libxslt to crash on ppc64
+
+Host: clean Ubuntu Disco with QEMU 3.1
+
+Guest: Alpine Linux edge with xmlto
+
+Steps to set up guest:
+curl -O http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/vmlinuz-vanilla
+curl -O http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/initramfs-vanilla
+qemu-system-ppc64 -m 1G -kernel vmlinuz-vanilla -initrd initramfs-vanilla -append "console=hvc0 ip=dhcp alpine_repo=http://dl-cdn.alpinelinux.org/alpine/edge/main/ modloop=http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/modloop-vanilla" -device virtio-rng-pci -nographic
+This brings up an VM with an in-memory Alpine Linux.
+
+Steps to reproduce:
+Login as root and execute the following commands.
+apk add xmlto
+ntpd -nqp time.google.com // For TLS OCSP
+wget https://ddosolitary.org/manpage-base.xsl
+wget https://ddosolitary.org/shadowsocks-libev.xml
+xmlto -m manpage-base.xsl man shadowsocks-libev.xml
+The downloaded files are from this project: https://github.com/shadowsocks/shadowsocks-libev The former is directly taken from the "doc" directory and the latter is an intermediate build output generated by asciidoc from doc/shadowsocks-libev.asciidoc
+
+Expected behavior: The command silently succeeds producing shadowsocks-libev.8
+
+Actual behavior: 
+runtime error: file file:///usr/share/xml/docbook/xsl-stylesheets-1.79.1/manpages/tbl.xsl line 450 element text
+xsltApplySequenceConstructor: A potential infinite template recursion was detected.
+You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number of nested template calls and variables/params (currently set to 3000).
+Templates:
+#0 name process.colspan
+#1 name process.colspan
+#2 name process.colspan
+#3 name process.colspan
+#4 name process.colspan
+#5 name process.colspan
+#6 name process.colspan
+#7 name process.colspan
+#8 name process.colspan
+#9 name process.colspan
+#10 name process.colspan
+#11 name process.colspan
+#12 name process.colspan
+#13 name process.colspan
+#14 name process.colspan
+Variables:
+#0
+type
+colspan
+#1
+colspan
+#2
+type
+colspan
+#3
+colspan
+#4
+type
+colspan
+#5
+colspan
+#6
+type
+colspan
+#7
+colspan
+#8
+type
+colspan
+#9
+colspan
+#10
+type
+colspan
+#11
+colspan
+#12
+type
+colspan
+#13
+colspan
+#14
+type
+colspan
+error: file /root/shadowsocks-libev.xml
+xsltRunStylesheet : run failed
+
+Note:
+I tried increasing --maxdepth as suggested in the error output but that will result in a segfault.
+This error doesn't occur with an older QEMU (I tested QEMU 2.12 on Ubuntu Cosmic) or different architectures on QEMU 3.1 (I tested x86, x86_64, arm, aarch64, s390x). Also it didn't help to use an older Alpine Linux (I tested v3.8). So I think it is caused by a bug in QEMU rather than the distro/package.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1818483 b/results/classifier/gemma3:12b/files/1818483
new file mode 100644
index 000000000..4c77a69e9
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1818483
@@ -0,0 +1,43 @@
+
+qemu user mode does not support binfmt_misc config with flags include "P"
+
+Hi Sir:
+During our test in chroot environment with qemu-user-static, we got some test cases failed because of program output warning with unexpected full path name.
+For example in test module "Devscripts"
+the test item for broken tarball expected the warning info:
+<tar: This does not look like a tar archive
+tar: ******* >
+but the output was:
+</bin/tar: This does not look like a tar archive
+/bin/tar: ******>
+the cause is the config file of binfmt_misc was set not to send argv0, for example:
+type command "tar" after chroot:
+==========================
+lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot .
+[sudo] password for lpeng: 
+root@lpeng-VirtualBox:/# tar
+/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options
+Try '/bin/tar --help' or '/bin/tar --usage' for more information.
+root@lpeng-VirtualBox:/# 
+===========================
+
+by adding output log in main()@qemu/Linux-user/main.c
+we found the original input command was changed, and qemu do not know that, we got the input args:
+argv_0----/usr/bin/qemu-mips64el-static---
+argv_1----/bin/tar---
+argv_2----NULL---
+
+Next step we modified the flags=P in the corresponding config under folder /proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu.
+But chroot could not start bash because in current qemu dose not consider about this unexpected one more"argv[0]"
+
+
+After modified qemu code temporary to handle the new argv list we got the input args, and from argv[2] is the original input command
+argv_0----/usr/bin/qemu-mips64el-static---
+argv_1----/bin/tar---
+argv_2----tar---
+
+We need the original input from command line, so is it possible that let binfmt_misc to pass one more additional args or env to qemu as a token of the binfmt_misc flag, then qemu can judge how to parse the input args by it?
+looking forward your suggestions.
+
+Thanks
+luyou
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1819182 b/results/classifier/gemma3:12b/files/1819182
new file mode 100644
index 000000000..d09bb4d32
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1819182
@@ -0,0 +1,24 @@
+
+info does not recognize file format of vpc with subformat=fixed
+
+After creating or converting an image to vpc with 'subformat=fixed'
+'qemu-img info' incorrectly identifies the image as 'raw' format.
+
+$ qemu-img --version
+qemu-img version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.10)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+$ qemu-img create -f vpc -o subformat=fixed my.vpc 2G
+Formatting 'my.vpc', fmt=vpc size=2147483648 subformat=fixed
+
+$ qemu-img info my.vpc
+image: my.vpc
+file format: raw
+virtual size: 2.0G (2147992064 bytes)
+disk size: 4.0K
+
+$ qemu-img info -f vpc my.vpc
+image: my.vpc
+file format: vpc
+virtual size: 2.0G (2147991552 bytes)
+disk size: 4.0K
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/files/1819343 b/results/classifier/gemma3:12b/files/1819343
new file mode 100644
index 000000000..8fb9efb9e
--- /dev/null
+++ b/results/classifier/gemma3:12b/files/1819343
@@ -0,0 +1,8 @@
+
+Qcow2 image stuck as locked after host crash
+
+After a host crash, the qcow2 image of the VM, stored on a remote NFS share, has become inaccessible. Libvirt/QEMU reports that 'failed to get "write" lock\nIs another process using the image [/path/nfs/image.qcow2]?'. No process is accessing the image from either host or the network share side. There is no obvious way in qemu-img to force unlocking the file or repair the image (attempting a qemu-img check with -r all results in qemu-img complaining about the lock and being unable to do force-share=on on anything but readonly images).
+
+I'm currently attempting to fix this by converting the image via 'qemu-img convert -U -f qcow2 -O qcow2 image.qcow2 image_2.gcow2', though this will likely take some time.
+
+Using QEMU 3.1.0
\ No newline at end of file