add 18th iteration of classifier

1 files changed, 82 insertions, 0 deletions

diff --git a/results/classifier/118/performance/2562 b/results/classifier/118/performance/2562
new file mode 100644
index 00000000..35bd9e52
--- /dev/null
+++ b/results/classifier/118/performance/2562
@@ -0,0 +1,82 @@
+performance: 0.889
+architecture: 0.866
+semantic: 0.856
+graphic: 0.851
+boot: 0.841
+assembly: 0.839
+user-level: 0.823
+debug: 0.818
+peripherals: 0.798
+PID: 0.798
+device: 0.792
+permissions: 0.788
+register: 0.787
+arm: 0.771
+mistranslation: 0.748
+risc-v: 0.724
+socket: 0.695
+x86: 0.692
+VMM: 0.691
+kernel: 0.686
+network: 0.682
+hypervisor: 0.678
+ppc: 0.657
+virtual: 0.634
+KVM: 0.634
+files: 0.602
+vnc: 0.582
+TCG: 0.554
+i386: 0.507
+
+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.