7 files changed, 309 insertions, 0 deletions
diff --git a/results/classifier/108/other/256 b/results/classifier/108/other/256
new file mode 100644
index 00000000..d3cc3de3
--- /dev/null
+++ b/results/classifier/108/other/256
@@ -0,0 +1,16 @@
+device: 0.736
+debug: 0.448
+graphic: 0.431
+PID: 0.232
+network: 0.175
+permissions: 0.169
+boot: 0.161
+other: 0.129
+semantic: 0.127
+performance: 0.103
+vnc: 0.056
+files: 0.046
+socket: 0.046
+KVM: 0.003
+
+`make install` fails on documentation when using Sphinx 4
diff --git a/results/classifier/108/other/2560 b/results/classifier/108/other/2560
new file mode 100644
index 00000000..4d1bbcd0
--- /dev/null
+++ b/results/classifier/108/other/2560
@@ -0,0 +1,120 @@
+other: 0.896
+permissions: 0.893
+device: 0.884
+performance: 0.883
+semantic: 0.881
+debug: 0.855
+graphic: 0.842
+socket: 0.841
+boot: 0.834
+files: 0.826
+PID: 0.818
+network: 0.804
+vnc: 0.797
+KVM: 0.650
+
+Go garbage collector crashes when using qemu-x86_64 on an aarch64 host
+Description of problem:
+Apps compiled for Go and the Go compiler/tool itself crash when they are run with `qemu-x86_64` on an AARCH64 host system. This was not a problem on QEMU 8.2.x (I bisected, see further down). I also seem to recall that Go 1.21 is fine on QEMU 9.x, so maybe some recent change in Go 1.22 + recent changes in QEMU broke something?
+
+The crash from Go seems to be in the garbage collector, I cannot reproduce the issue when I disable the GC with `GOGC=off`.
+
+Output from Go when it crashes:
+
+```
+$ sudo chroot . go build main.go
+runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0
+fatal error: lfstack.push
+
+runtime stack:
+runtime.throw({0xa95b29?, 0x797b1e2a383c?})
+        runtime/panic.go:1023 +0x5c fp=0xc000515f08 sp=0xc000515ed8 pc=0x43c27c
+runtime.(*lfstack).push(0x0?, 0xc0005041c0?)
+        runtime/lfstack.go:29 +0x125 fp=0xc000515f48 sp=0xc000515f08 pc=0x40fd45
+runtime.(*spanSetBlockAlloc).free(...)
+        runtime/mspanset.go:322
+runtime.(*spanSet).reset(0xf46980)
+        runtime/mspanset.go:264 +0x79 fp=0xc000515f78 sp=0xc000515f48 pc=0x437219
+runtime.finishsweep_m()
+        runtime/mgcsweep.go:258 +0x8d fp=0xc000515fb8 sp=0xc000515f78 pc=0x42a6cd
+runtime.gcStart.func2()
+        runtime/mgc.go:685 +0xf fp=0xc000515fc8 sp=0xc000515fb8 pc=0x46e40f
+runtime.systemstack(0x0)
+        runtime/asm_amd64.s:509 +0x4a fp=0xc000515fd8 sp=0xc000515fc8 pc=0x47442a
+````
+Steps to reproduce:
+0. Use an aarch64 host system!
+
+1. Set up binfmt to use qemu-x86_64:
+
+```
+$ cat /proc/sys/fs/binfmt_misc/qemu-x86_64
+enabled
+interpreter /usr/bin/qemu-x86_64
+flags: OCF
+offset 0
+magic 7f454c4602010100000000000000000002003e00
+mask fffffffffffefe00fffffffffffffffffeffffff
+```
+
+2. Download/extract x86_64 rootfs:
+
+```
+$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.2-x86_64.tar.gz	
+```
+
+3. Create example app in the x86_64 rootfs:
+
+```
+package main
+
+func main() {
+}
+```
+
+4. Build using chroot:
+
+```
+$ sudo chroot /path/to/x86_64/rootfs apk add go
+$ sudo chroot /path/to/x86_64/rootfs go build main.go
+runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0
+fatal error: lfstack.push
+...
+```
+
+5. As noted previously, if the Go garbage collector is disabled, then it works, presumably because it avoids the bug(?) in QEMU:
+
+```
+$ sudo chroot . env GOGC=off go build main.go
+# might have to mount /dev to build successfully, but Go doesn't panic!
+```
+Additional information:
+I've bisected this exact crash/failure to:
+
+```
+commit 2952b642a555207748dd961fcbfdc48f198eebb6
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Feb 13 10:20:27 2024 -1000
+
+    linux-user: Split out do_munmap
+
+    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+```
+
+Though a different crash starts happening at the commit before that one:
+
+```
+commit ad87d26e6bb13257409f412224c862fc54025e8b
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Jan 2 12:57:55 2024 +1100
+
+    linux-user: Do early mmap placement only for reserved_va
+
+    For reserved_va, place all non-fixed maps then proceed
+    as for MAP_FIXED.
+
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+```
+
+FYI @rth7680
diff --git a/results/classifier/108/other/2561 b/results/classifier/108/other/2561
new file mode 100644
index 00000000..66749aa9
--- /dev/null
+++ b/results/classifier/108/other/2561
@@ -0,0 +1,54 @@
+graphic: 0.755
+files: 0.679
+device: 0.640
+PID: 0.588
+KVM: 0.572
+socket: 0.512
+permissions: 0.468
+boot: 0.446
+performance: 0.429
+semantic: 0.417
+vnc: 0.405
+debug: 0.399
+network: 0.374
+other: 0.338
+
+Sound doesnt work on debian guest + debian host using Pipewire
+Description of problem:
+There is no sound on Debian Stable VM. Im using SPICE for audio redirection.
+Steps to reproduce:
+1. Download debian stable ISO (12 atm)
+2. Install it on your KVM
+3. Make sure your host and your guest are using pipewire (check https://wiki.debian.org/PipeWire#Installation)
+4. No sound is transmitted to the host.
+Additional information:
+- I have tried switching SPICE to something else like ALSA, but it will result in hanging of the video page similar to this video: 
+
+https://github.com/QubesOS/qubes-issues/issues/1698#issuecomment-1031376517
+
+- Tried to use direct pipewire, but resulted into error:
+
+```
+Error starting domain: internal error: process exited while connecting to monitor: 2024-09-04T18:13:40.241754Z qemu-system-x86_64: Unknown audio driver pipewire'. Perhaps you want to install qemu-system-gui package?
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
+    callback(*args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
+    ret = fn(self, *args, **kwargs)
+          ^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup
+    self._backend.create()
+  File "/usr/lib/python3/dist-packages/libvirt.py", line 1379, in create
+    raise libvirtError('virDomainCreate() failed')
+libvirt.libvirtError: internal error: process exited while connecting to monitor: 2024-09-04T18:13:40.241754Z qemu-system-x86_64: Unknown audio driver pipewire'. Perhaps you want to install qemu-system-gui package?
+```
+
+Yes i have installed "qemu-system-gui" but still got the same message.
+
+
+Debian XML with SPICE:
+
+[Debian-XML.txt](/uploads/66e09b37f672b49f8f0a0a01d3c6a6b2/Debian-XML.txt)
diff --git a/results/classifier/108/other/2562 b/results/classifier/108/other/2562
new file mode 100644
index 00000000..6bc07194
--- /dev/null
+++ b/results/classifier/108/other/2562
@@ -0,0 +1,67 @@
+performance: 0.889
+semantic: 0.856
+graphic: 0.851
+other: 0.842
+boot: 0.841
+debug: 0.818
+PID: 0.798
+device: 0.792
+permissions: 0.788
+socket: 0.695
+network: 0.682
+KVM: 0.634
+files: 0.602
+vnc: 0.582
+
+Booting EFI shell from GRUB using "chainloader" in Qemu with UEFI boot shows video artifacts if we have all_video, gfxterm
+Steps to reproduce:
+- Start Qemu in UEFI mode, i. e. `qemu-system-x86_64 -bios OVMF.fd ...`
+- Qemu should load GRUB from the disk as the first thing after firmware
+- GRUB should run commands `loadfont unicode; insmod all_video; terminal_output gfxterm` (note: this is perfectly ordinary sequence executed by Debian's default configuration)
+- Then GRUB should execute EFI shell using `chainloader` command
+
+If we do all this, then instead of EFI shell we will see broken image. I. e. video output will be completely broken/mangled/damaged. But EFI shell will still respond to commands. If we type "exit", then we will exit from EFI shell back to GRUB.
+
+I will repeat: my configuration is not special at all. `loadfont unicode; insmod all_video; terminal_output gfxterm` are absolutely ordinary commands executed by Debian's GRUB default setup. So, essentially this bug means this: if I add EFI shell to GRUB menu in Debian, then this new menu entry will not work properly if I try to boot in Qemu in UEFI mode.
+
+Okay, now let me give you more detailed steps to reproduce.
+
+- Execute the following script on Linux x86_64 host:
+```bash
+#!/bin/bash
+# This script was tested on Debian trixie (as on 2024-09-07) with the following packages installed:
+# dosfstools grub-efi-amd64-bin qemu-system-x86 ovmf efi-shell-x64
+set -e
+DIR="$(mktemp -d /tmp/qemu-bug-XXXXXX)"
+truncate --size=100M "$DIR/disk"
+echo ',+,' | sfdisk --label gpt "$DIR/disk"
+LOOP="$(losetup --find --show --partscan --nooverlap "$DIR/disk")"
+sleep 1
+mkfs.vfat "${LOOP}p1"
+mkdir "$DIR/root"
+mount "${LOOP}p1" "$DIR/root"
+losetup --detach "$LOOP"
+mkdir -p "$DIR/root/EFI/boot" "$DIR/root/boot/grub/fonts"
+grub-mkimage --format=x86_64-efi --output="$DIR/root/EFI/boot/bootx64.efi" --prefix=/boot/grub part_gpt fat
+cp -r /usr/lib/grub/x86_64-efi "$DIR/root/boot/grub"
+cp /usr/share/efi-shell-x64/shellx64.efi "$DIR/root/boot"
+cp /usr/share/grub/unicode.pf2 "$DIR/root/boot/grub/fonts"
+cat << "EOF" > "$DIR/root/boot/grub/grub.cfg"
+loadfont unicode
+insmod all_video
+terminal_output gfxterm
+menuentry "EFI shell" {
+  chainloader /boot/shellx64.efi
+}
+EOF
+umount "$DIR/root"
+qemu-system-x86_64 -m 2048 -bios OVMF.fd -drive file="$DIR/disk",format=raw
+```
+- When you see Qemu window, choose "EFI shell" menu entry in GRUB menu
+- You will immediately see damaged video output instead of proper EFI shell
+
+This bug doesn't reproduce on real hardware, i. e. without Qemu!!! I. e. this is Qemu bug. Qemu task is to duplicate real hardware behaviour. On real hardware there is no this bug, so Qemu should not have it, either.
+
+Note: if I remove `loadfont unicode; insmod all_video; terminal_output gfxterm`, then the bug disappears.
+
+Also note: if I replace `all_video` with `efi_gop`, then the bug disappears, too. So, workaround is to use `efi_gop` instead of `all_video` in UEFI mode. But I still believe the bug is in Qemu, because `all_video` doesn't cause any problems on real hardware, so Qemu should work, too.
diff --git a/results/classifier/108/other/2564 b/results/classifier/108/other/2564
new file mode 100644
index 00000000..b4aebc2e
--- /dev/null
+++ b/results/classifier/108/other/2564
@@ -0,0 +1,16 @@
+performance: 0.732
+device: 0.671
+network: 0.490
+permissions: 0.334
+files: 0.305
+PID: 0.305
+socket: 0.249
+boot: 0.197
+graphic: 0.188
+debug: 0.184
+semantic: 0.180
+vnc: 0.159
+other: 0.101
+KVM: 0.045
+
+ubuntu-22.04-s390x-all-system CI job often times out
diff --git a/results/classifier/108/other/2568 b/results/classifier/108/other/2568
new file mode 100644
index 00000000..0c730052
--- /dev/null
+++ b/results/classifier/108/other/2568
@@ -0,0 +1,16 @@
+device: 0.630
+network: 0.603
+permissions: 0.444
+graphic: 0.371
+files: 0.351
+performance: 0.333
+semantic: 0.293
+other: 0.224
+socket: 0.178
+debug: 0.136
+boot: 0.114
+vnc: 0.067
+PID: 0.030
+KVM: 0.013
+
+[AARCH64] HPFAR_EL2.NS not set for non secure read in S-EL1
diff --git a/results/classifier/108/other/2569 b/results/classifier/108/other/2569
new file mode 100644
index 00000000..020bf629
--- /dev/null
+++ b/results/classifier/108/other/2569
@@ -0,0 +1,20 @@
+graphic: 0.832
+device: 0.622
+semantic: 0.537
+debug: 0.341
+files: 0.336
+other: 0.280
+network: 0.214
+PID: 0.201
+performance: 0.200
+vnc: 0.157
+boot: 0.148
+socket: 0.082
+permissions: 0.072
+KVM: 0.006
+
+The alpha target doesn't support tcg plugin register tracking due to missing XML
+Description of problem:
+There is no register tracking because we build our register list based on XML and there was no XML for alpha because its so old. We could synthesise one to cover the register to fix this.
+Steps to reproduce:
+1. ./qemu-alpha -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=\* ./tests/tcg/alpha-linux-user/hello-alpha