add deepseek and gemma results

author: Christian Krinitsin <mail@krinitsin.com> 2025-07-03 07:27:52 +0000
committer: Christian Krinitsin <mail@krinitsin.com> 2025-07-03 07:27:52 +0000
commit: d0c85e36e4de67af628d54e9ab577cc3fad7796a (patch)
tree: f8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/gemma3:12b/boot
parent: 7f4364274750eb8cb39a3e7493132fca1c01232e (diff)
download: qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz
qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip
325 files changed, 10035 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/boot/1013888 b/results/classifier/gemma3:12b/boot/1013888
new file mode 100644
index 000000000..4b6247ac4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1013888
@@ -0,0 +1,8 @@
+
+windows xp sp3 setup blank screen on boot
+
+When attempting to run Windows XP SP3 setup in qemu on a Lubuntu host with the following kernel:
+
+Linux michael-XPS-M1530 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
+
+Qemu does not get past a blank screen after "Setup is inspecting your computer's hardware configuration"
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1021649 b/results/classifier/gemma3:12b/boot/1021649
new file mode 100644
index 000000000..da402cc89
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1021649
@@ -0,0 +1,10 @@
+
+qemu 1.1.0 waits for a keypress at boot
+
+qemu 1.1.0 waits for a keypress at boot.  Please don't ever do this.
+
+Try the attached test script.  When run it will initially print nothing, until you hit a key on the keyboard.
+
+Removing -nographic fixes the problem.
+
+Using virtio-scsi instead of virtio-blk fixes the problem.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1026176 b/results/classifier/gemma3:12b/boot/1026176
new file mode 100644
index 000000000..c163b6955
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1026176
@@ -0,0 +1,22 @@
+
+unable to boot squashfs through mtd device
+
+Hi,
+
+I have built latest qemu archive qemu-1.1.1 to be sure of up to date source code.
+I have then built buildroot squashfs image, which can be used correctly with cmdline like:
+
+qemu-system-i386 -m 64 -k fr -boot c -kernel images/bzImage -drive if=ide,file=images/rootfs.squashfs  -append "root=/dev/sda"
+
+Then I wanted to modify cmdline to use real MTD device, like:
+
+qemu-system-i386 -m 64 -k fr -boot c -kernel images/bzImage -drive if=mtd,file=images/rootfs.squashfs  -append "root=/dev/mtdblock0".
+
+But nothing was good under kernel.
+Even if mtd0 is reported through qemu interface (Ctrl Alt+2), no device can be found under kernel even if all drivers are built to use it.
+
+Is this feature okay on qemu-1.1.1 ??
+did I do mistake in my cmdline??
+
+thank you for your help.
+regards,
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1042084 b/results/classifier/gemma3:12b/boot/1042084
new file mode 100644
index 000000000..a610a1774
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1042084
@@ -0,0 +1,10 @@
+
+Windows 7 guest cannot boot after seabios updated
+
+Hi,
+
+I can no longer boot my Windows 7 guest after this commit (update seabios to latest master)
+
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=01afdadc92e71e29700e64f3a5f42c1c543e3cf9
+
+When I tried to boot Windows, it BSOD and said "The BIOS in this system is not fully ACPI compliant. Please contact your system vendor for an updated  BIOS". Reverting this commit will fix the issue.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1054 b/results/classifier/gemma3:12b/boot/1054
new file mode 100644
index 000000000..b0e193833
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1054
@@ -0,0 +1,31 @@
+
+Unable to start CirrOS 0.5.1 on QEMU 7.0 with -M virt and -cpu max
+Description of problem:
+
+Steps to reproduce:
+1. Fetch CirrOS image: ```wget https://github.com/cirros-dev/cirros/releases/download/0.5.1/cirros-0.5.1-aarch64-disk.img```
+2. Run QEMU:
+   ```
+   qemu-system-aarch64 -drive file=cirros-0.5.1-aarch64-disk.img -M virt -m 2048 \
+      -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -cpu max -nographic
+   ```
+Additional information:
+When image boots, GRUB window appears for a second and then kernel/initramfs are loaded and booted:
+```
+EFI stub: Booting Linux Kernel...
+EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
+EFI stub: Using DTB from configuration table
+EFI stub: Exiting boot services and installing virtual address map...
+```
+
+When everything is fine we can see kernel output:
+```
+[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070]
+[    0.000000] Linux version 5.3.0-26-generic (buildd@bos02-arm64-028) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #28~18.04.1-Ubuntu SMP Wed Dec 18 16:41:01 UTC 2019 (Ubuntu 5.3.0-26.28~18.04.1-generic 5.3.13)
+[    0.000000] efi: Getting EFI parameters from FDT:
+[    0.000000] efi: EFI v2.70 by EDK II
+```
+
+But on QEMU 7.0 with ```-M virt -cpu max``` we never get kernel output.
+
+#
diff --git a/results/classifier/gemma3:12b/boot/1062220 b/results/classifier/gemma3:12b/boot/1062220
new file mode 100644
index 000000000..1eded393f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1062220
@@ -0,0 +1,29 @@
+
+qemu-system-arm crashed with SIGABRT in cpu_abort()
+
+-kernel u-boot.bin
+
+ProblemType: Crash
+DistroRelease: Ubuntu 12.10
+Package: qemu-system 1.2.0-2012.09-0ubuntu1
+ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
+Uname: Linux 3.5.0-10-generic x86_64
+NonfreeKernelModules: nvidia
+ApportVersion: 2.6.1-0ubuntu1
+Architecture: amd64
+CrashCounter: 1
+Date: Fri Oct  5 19:30:23 2012
+ExecutablePath: /usr/bin/qemu-system-arm
+InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110804)
+ProcCmdline: qemu-system-arm -M versatilepb -kernel u-boot.bin
+Signal: 6
+SourcePackage: qemu-linaro
+StacktraceTop:
+ raise () from /lib/x86_64-linux-gnu/libc.so.6
+ abort () from /lib/x86_64-linux-gnu/libc.so.6
+ ?? ()
+ ?? ()
+ ?? ()
+Title: qemu-system-arm crashed with SIGABRT in raise()
+UpgradeStatus: Upgraded to quantal on 2012-08-11 (54 days ago)
+UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare vboxusers
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1063 b/results/classifier/gemma3:12b/boot/1063
new file mode 100644
index 000000000..e99fe5c9c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1063
@@ -0,0 +1,10 @@
+
+qemu: could not load PC BIOS 'bios-256k.bin'
+Description of problem:
+I cloned latest QEMU and build in Ubuntu 18.04, when I run QEMU to start a vm, it tells me `could not load PC BIOS 'bios-256k.bin'
+
+![image](/uploads/ce3eecac2f3a840e29f764d18a515dfd/image.png)
+Steps to reproduce:
+1. Clone latest QEMU in Ubuntu18.04
+2. build QEMU
+3. Use QEMU and libvirt to start a virtual machine.
diff --git a/results/classifier/gemma3:12b/boot/1081416 b/results/classifier/gemma3:12b/boot/1081416
new file mode 100644
index 000000000..7018b450e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1081416
@@ -0,0 +1,43 @@
+
+Qemu 1.2.0 crashes when using tcp serial console and GRUB boots
+
+When booting OpenWRT Attitude Adjustement ( http://downloads.openwrt.org/attitude_adjustment/12.09-beta2/x86/generic/openwrt-x86-generic-combined-ext4.img.gz ) with this command line:
+qemu-system-x86_64 -serial tcp:127.0.0.1:4444 -hda openwrt-x86-generic-combined-ext4.img
+
+Qemu crashes as soon as GRUB starts, after network cards start.
+
+*** buffer overflow detected ***: /usr/bin/qemu-system-x86_64 terminated
+======= Backtrace: =========
+/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7ffff45f2ad7]
+/usr/lib/libc.so.6(+0xf9bb0)[0x7ffff45f0bb0]
+/usr/lib/libc.so.6(+0xfba47)[0x7ffff45f2a47]
+/usr/bin/qemu-system-x86_64[0x46a628]
+/usr/bin/qemu-system-x86_64[0x4e8a14]
+/usr/bin/qemu-system-x86_64[0x4e802b]
+/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7ffff4518725]
+/usr/bin/qemu-system-x86_64[0x40d949]
+
+
+Here is a GDB backtrace:
+
+Program received signal SIGABRT, Aborted.
+0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6
+(gdb) bt
+#0  0x00007ffff452bfa5 in raise () from /usr/lib/libc.so.6
+#1  0x00007ffff452d428 in abort () from /usr/lib/libc.so.6
+#2  0x00007ffff456acfb in __libc_message () from /usr/lib/libc.so.6
+#3  0x00007ffff45f2ad7 in __fortify_fail () from /usr/lib/libc.so.6
+#4  0x00007ffff45f0bb0 in __chk_fail () from /usr/lib/libc.so.6
+#5  0x00007ffff45f2a47 in __fdelt_warn () from /usr/lib/libc.so.6
+#6  0x000000000046a628 in qemu_iohandler_poll (readfds=0xdb7da0 <rfds>, 
+    writefds=0xdb7e20 <wfds>, xfds=0x6, xfds@entry=0xdb7ea0 <xfds>, ret=-1, 
+    ret@entry=1) at iohandler.c:121
+#7  0x00000000004e8a14 in main_loop_wait (nonblocking=<optimized out>)
+    at main-loop.c:497
+#8  0x00000000004e802b in main_loop ()
+    at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:1643
+#9  main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
+    at /usr/src/aur/qemu/src/qemu-1.2.0/vl.c:3755
+(gdb) 
+
+Here is a more useless dump...
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1098 b/results/classifier/gemma3:12b/boot/1098
new file mode 100644
index 000000000..6db85cc58
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1098
@@ -0,0 +1,12 @@
+
+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/gemma3:12b/boot/1115 b/results/classifier/gemma3:12b/boot/1115
new file mode 100644
index 000000000..3fc8299fd
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1115
@@ -0,0 +1,15 @@
+
+qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk
+Description of problem:
+When trying to boot an MBR Windows guest with SeaBios, it is stuck at the blue Windows boot logo, before the loading circle.
+Changing the vGPU doesn't help, 0% cpu load just frozen. Even if I boot a WinPE iso, the same happens.
+Even after 30 minutes, the same.
+Rebooted host multiple times.
+Since SeaBios is the default in qemu and virt-manager I imagine many VMs are installed as MBR and thus will be stuck.
+To boot the VM I have to:
+- switch to UEFI (TianoCore)
+- boot WinPE iso
+- use proprietary software to convert the Windows disk from MBR to GPT
+Then it boots just fine but I imagine not many users will be able to do this.
+Steps to reproduce:
+1. boot Windows image / WinPE iso with SeaBios
diff --git a/results/classifier/gemma3:12b/boot/1120 b/results/classifier/gemma3:12b/boot/1120
new file mode 100644
index 000000000..a0b9e195a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1120
@@ -0,0 +1,13 @@
+
+Multiboot direct loading broken.
+Description of problem:
+This is my kernel and it's multiboot loader. It passed the check of `grub-file`, but QEMU could not load it.
+```
+qemu-system-i386: Error loading uncompressed kernel without PVH ELF Note
+```
+
+When I add `-machine type=pc-i440fx-3.1`, QEMU shows `qemu: linux kernel too old to load a ram disk` or `qemu: invalid kernel header`.
+
+The multiboot file is linked with `ld.lld -s -o`.
+
+[toop](/uploads/7f230dc39d6a3a8c43c4c720d31878c6/toop)[multiboot](/uploads/59faa4607dc2837b54c89b35db6f206a/multiboot)
diff --git a/results/classifier/gemma3:12b/boot/1121 b/results/classifier/gemma3:12b/boot/1121
new file mode 100644
index 000000000..19f410689
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1121
@@ -0,0 +1,71 @@
+
+Segmentation fault in aspeed-hace
+Description of problem:
+
+Steps to reproduce:
+1. run qemu-machine nf5280m7-bmc
+2. it will seg falult when load fitimage
+Additional information:
+Captured by gdb
+
+```
+0x00007ffff6e08a06 in has_padding (pad_offset=<synthetic pointer>, total_msg_len=<synthetic pointer>, req_len=17, total_req_len=56476, iov=0x7ffff5e973c0) at ../hw/misc/aspeed_hace.c:129
+129	       if (padding[*pad_offset] == 0x80) {
+(gdb) p padding_size
+$1 = 45
+(gdb) p *padding_offset
+No symbol "padding_offset" in current context.
+(gdb) p *pad_offset
+$2 = 4294967268
+(gdb) bt
+#0  0x00007ffff6e08a06 in has_padding (pad_offset=<synthetic pointer>, total_msg_len=<synthetic pointer>, req_len=17, total_req_len=56476, 
+    iov=0x7ffff5e973c0) at ../hw/misc/aspeed_hace.c:129
+#1  gen_acc_mode_iov (cache=0x7ffff7fd5600 <iov_cache>, total_req_len=0x7ffff7fd55e4 <total_len>, count=0x7ffff7fd55e0 <count>, 
+    req_len=0x7ffff5e973a8, id=<optimized out>, iov=0x7ffff5e973b0) at ../hw/misc/aspeed_hace.c:176
+#2  do_hash_operation (s=s@entry=0x7ffff60077b0, algo=3, sg_mode=sg_mode@entry=true, acc_mode=acc_mode@entry=true)
+    at ../hw/misc/aspeed_hace.c:235
+#3  0x00007ffff6e09001 in aspeed_hace_write (opaque=<optimized out>, addr=12, data=262488, size=<optimized out>)
+    at ../hw/misc/aspeed_hace.c:372
+#4  0x00007ffff706ad54 in memory_region_write_accessor (mr=mr@entry=0x7ffff6007ad0, addr=48, value=value@entry=0x7ffff5e98548, 
+    size=size@entry=4, shift=<optimized out>, mask=mask@entry=4294967295, attrs=...) at ../softmmu/memory.c:492
+#5  0x00007ffff7068266 in access_with_adjusted_size_aligned (addr=addr@entry=48, value=value@entry=0x7ffff5e98548, size=size@entry=4, 
+    access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x7ffff706acd0 <memory_region_write_accessor>, 
+    mr=0x7ffff6007ad0, attrs=...) at ../softmmu/memory.c:553
+#6  0x00007ffff706c948 in memory_region_dispatch_write (mr=mr@entry=0x7ffff6007ad0, addr=addr@entry=48, data=<optimized out>, 
+    data@entry=262488, op=op@entry=MO_32, attrs=...) at ../softmmu/memory.c:1650
+#7  0x00007ffff7157ea9 in io_writex (env=env@entry=0x7ffff5fe7f10, iotlbentry=0x7fff6803f200, mmu_idx=mmu_idx@entry=7, val=val@entry=262488, 
+    addr=addr@entry=510459952, retaddr=retaddr@entry=140736149505328, op=MO_32) at ../accel/tcg/cputlb.c:1429
+#8  0x00007ffff715c7dc in store_helper (op=MO_32, retaddr=140736149505328, oi=<optimized out>, val=262488, addr=510459952, 
+    env=0x7ffff5fe7f10) at ../accel/tcg/cputlb.c:2363
+#9  full_le_stl_mmu (env=0x7ffff5fe7f10, addr=<optimized out>, val=262488, oi=<optimized out>, retaddr=140736149505328)
+    at ../accel/tcg/cputlb.c:2451
+#10 0x00007fffb032c530 in code_gen_buffer ()
+#11 0x00007ffff714eace in cpu_tb_exec (cpu=cpu@entry=0x7ffff5fde1b0, itb=itb@entry=0x7fffb033e7c0 <code_gen_buffer+3401619>, 
+    tb_exit=tb_exit@entry=0x7ffff5e98c2c) at ../accel/tcg/cpu-exec.c:357
+#12 0x00007ffff714fc68 in cpu_loop_exec_tb (tb_exit=0x7ffff5e98c2c, last_tb=<synthetic pointer>, 
+    tb=0x7fffb033e7c0 <code_gen_buffer+3401619>, cpu=0x7ffff5fde1b0) at ../accel/tcg/cpu-exec.c:847
+#13 cpu_exec (cpu=cpu@entry=0x7ffff5fde1b0) at ../accel/tcg/cpu-exec.c:1006
+#14 0x00007ffff7163d54 in tcg_cpus_exec (cpu=cpu@entry=0x7ffff5fde1b0) at ../accel/tcg/tcg-accel-ops.c:68
+#15 0x00007ffff7163ea7 in mttcg_cpu_thread_fn (arg=arg@entry=0x7ffff5fde1b0) at ../accel/tcg/tcg-accel-ops-mttcg.c:96
+#16 0x00007ffff7344c31 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:556
+#17 0x00007ffff74c74eb in start_thread ()
+#18 0x00007ffff75649c0 in clone3 ()
+```
+the uboot: https://github.com/openbmc/u-boot/commit/0f245563c2cb3a6b4f1206db4f1a9f0325406094
+
+we should remove the hash check, otherwise,  the boot will stop at uboot-cli
+```
+diff --git a/common/image-fit.c b/common/image-fit.c
+index 3c8667f93d..c655b297e5 100644
+--- a/common/image-fit.c
++++ b/common/image-fit.c
+@@ -1193,7 +1193,7 @@ static int fit_image_check_hash(const void *fit, int noffset, const void *data,
+                return -1;
+        } else if (memcmp(value, fit_value, value_len) != 0) {
+                *err_msgp = "Bad hash value";
+-               return -1;
++               return 0;
+        }
+ 
+        return 0;
+```
diff --git a/results/classifier/gemma3:12b/boot/1122492 b/results/classifier/gemma3:12b/boot/1122492
new file mode 100644
index 000000000..ff8af3c84
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1122492
@@ -0,0 +1,47 @@
+
+qemu and grub2 rescue floppy don't get along
+
+With qemu.git as of Feb 11 2013:
+
+# grub2-mkrescue -o test.img
+# ./x86_64-softmmu/qemu-system-x86_64 -fda test.img -curses
+
+SeaBIOS (version ?-20130206_051134-ccnode4)
+
+iPXE v1.0.0-591-g7aee315
+iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+07FC7EC0+07F87EC0 C900
+
+
+Booting from Hard Disk...
+Boot failed: could not read the boot disk
+
+Booting from Floppy...
+GRUB loading....
+Welcome to GRUB!
+
+error: attempt to read or write outside of disk `fd0'.
+Entering rescue mode...
+grub rescue> 
+
+
+Expected results: grub header and a normal usable grub prompt like 'grub>'
+
+
+This was originally reported against qemu 0.15 in Fedora 16 at:
+
+https://bugzilla.redhat.com/show_bug.cgi?id=784537
+
+Some more info from that bug:
+
+0) The images that grub2-mkrescue creates are odd mixtures of ISO images and disk images:
+    file -r -k test.img
+    test.img: # ISO 9660 CD-ROM filesystem data 'ISOIMAGE                        ' (bootable)
+    - x86 boot sector; partition 1: ID=0xcd, active, starthead 0, startsector 1, 4455 sectors, code offset 0x63 DOS executable (COM), boot code
+
+1) The test image I use has a 2281472 byte size. If I append that with zeroes to 2880 KB (2949120 bytes) then I get the expected results. So there's a workaround. But I don't think it's an obvious workaround.
+
+2) It's debatable whether this is a bug. If it's considered a bug, I'm not sure whether qemu and/or grub2 is to blame. Should qemu (silently) handle (floppy) disk image between 1440 KB and 2880 KB as if they actually were 2880 KB in size? Or should grub2, if possible, zero pad the images it creates to (in this case) a 2880 KB size?
+
+3) Please note that there seems to be little one can do to leave "grub rescue" mode. Ie, "insmod normal" will fail too:
+    grub rescue> insmod normal
+    error: attempt to read or write outside of disk `fd0'.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1131 b/results/classifier/gemma3:12b/boot/1131
new file mode 100644
index 000000000..71f4cc1f0
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1131
@@ -0,0 +1,21 @@
+
+Multiboot: could not move values from provided mmap to another address directly.
+Description of problem:
+When using `-kernel` to load a Multiboot file which requires a memory map(MULTIBOOT_MEMORY_INFO flag) and trying to move the values in the provided mmap entries to another address directly, QEMU reboots.
+```c
+xxx = mmap->addr;
+```
+
+When moving with volatile, everything works well:
+```c
+volatile unsigned long long addr = mmap->addr;
+xxx = addr;
+```
+Steps to reproduce:
+1. Source code here: [github/xtexChooser/toop/boot/multiboot/src/multiboot.c](https://github.com/xtexChooser/toop/blob/51153319d4f2320ae9a9277ffffad3f67a335fe9/boot/multiboot/src/multiboot.c#L32)
+2. Minimized reproduce: [gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c](https://gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c)
+3. I am sure that 0x00001210 is writable, it is empty in the memory map and QEMU works correctly when writing a zero value to here.
+4. The reproducer is available without any module, when it works, it should keep running without any output, if QEMU reboots, the screen should flash as it clears and prints the BIOS information again.
+5. If move with volatile(as the `multiboot_works.c` in reproducer), the reproducer works correctly.
+Additional information:
+#
diff --git a/results/classifier/gemma3:12b/boot/1131757 b/results/classifier/gemma3:12b/boot/1131757
new file mode 100644
index 000000000..9ea4082bc
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1131757
@@ -0,0 +1,24 @@
+
+QEMU 1.4.0 fails to boot sparc64 linux image
+
+Hi!
+
+I tried to boot sparc64 linux image (http://packages.debian.org/sid/sparc64/linux-image-2.6-sparc64-smp/download) with qemu and received the  error.
+
+host:~$qemu-system-sparc64 -nographic -kernel vmlinuz-3.2.0-4-sparc64-smp
+OpenBIOS for Sparc64
+Configuration device id QEMU version tion device id QEMUkernel addr n device id QEMUkernel cmdline 
+CPUs:  cmdline 
+ x SUNW,UltraSPARC-IIi
+UUID: 00UltraSPARC-IIi
+Welcome to OpenBIOS v1.0 built on Aug 19 2012 13:06
+  Type 'help' for detailed information
+[sparc64] Kernel already loaded
+Unhandled Exception 0x0000000000000020
+PC = 0x0000000000404000 NPC = 0x0000000000404004
+Stopping execution
+
+Also, I tried to follow instruction from Artyom Tarasenko blog (http://tyom.blogspot.ru/2012/05/booting-linuxsparc64-on-todays-openbios.html), but it's still impossible to boot linux.
+
+Regards,
+Kirill
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1133 b/results/classifier/gemma3:12b/boot/1133
new file mode 100644
index 000000000..b1738e93e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1133
@@ -0,0 +1,11 @@
+
+unused memory filled with 0x00 instead of 0xFF
+Description of problem:
+Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem?
+
+Refer to
+https://bugs.launchpad.net/qemu/+bug/1180923
+Steps to reproduce:
+1.
+2.
+3.
diff --git a/results/classifier/gemma3:12b/boot/1135 b/results/classifier/gemma3:12b/boot/1135
new file mode 100644
index 000000000..1135ea608
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1135
@@ -0,0 +1,13 @@
+
+Multiboot: invalid multiboot information block
+Description of problem:
+Breakpoint at 0x85d4, this is the entrypoint of this Multiboot loader.
+According to the Multiboot specification, the EAX register should be a pointer to the Multiboot information block. When I am testing, it is 0x9500. However, when dumping the memory using `dump binary memory`, nearby memory areas are all zeros.
+
+When dumping some bigger memory aeras, I found that the module hasbeen loaded to the memory successfully, altough MBI was broken.
+Steps to reproduce:
+
+Additional information:
+multiboot: [multiboot](/uploads/55fdfcf30ada0af2d00badf11fcd308c/multiboot)
+
+toop: [toop](/uploads/de3b63ae021303c544105ba1498f3373/toop)
diff --git a/results/classifier/gemma3:12b/boot/1159 b/results/classifier/gemma3:12b/boot/1159
new file mode 100644
index 000000000..52501d6e8
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1159
@@ -0,0 +1,33 @@
+
+Strange invalid access errors for very basic OS
+Description of problem:
+Currently I'm studying OS development. I found numerous guides on that topic, however [this one](https://github.com/cfenollosa/os-tutorial/tree/master/01-bootsector-barebones) is most close to what I have been doing.  
+When `.bin` file is launched with `-d guest_errors` flag, before any OS output exactly 512 error messages appear in logs, that look like that:
+```
+Invalid access at addr 0xFEBB0000, size 1, region '(null)', reason: rejected
+Invalid access at addr 0x0, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFEBB0001, size 1, region '(null)', reason: rejected
+Invalid access at addr 0x1, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFEBB0002, size 1, region '(null)', reason: rejected
+...
+and it goes up to
+...
+Invalid access at addr 0xFEBB00FE, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFE, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFEBB00FF, size 1, region '(null)', reason: rejected
+Invalid access at addr 0xFF, size 1, region '(null)', reason: rejected
+```
+Apparently, the OS boots normally after that. Should I be concerned about these messages or Should I just ignore them?
+That looks strange and confusing, not a piece of my code calls these addresses. Maybe I'm doing something wrong?
+Steps to reproduce:
+1. Install `nasm` compiler (nasm package for apt)
+2. Create a file named `os.asm` with exactly four lines:
+```asm
+loop:
+    jmp loop
+times 510-($-$$) db 0
+dw 0xaa55
+```
+3. Build it with `nasm -f bin os.asm -o os.bin`
+4. Run it with `qemu-system-i386 -d guest_errors -drive format=raw,file=./os.bin`
+5. ...enjoy error messages.
diff --git a/results/classifier/gemma3:12b/boot/1160 b/results/classifier/gemma3:12b/boot/1160
new file mode 100644
index 000000000..8f9cc12a1
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1160
@@ -0,0 +1,2 @@
+
+hw/riscv reset vector improvement
diff --git a/results/classifier/gemma3:12b/boot/1163 b/results/classifier/gemma3:12b/boot/1163
new file mode 100644
index 000000000..aaa9dc998
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1163
@@ -0,0 +1,12 @@
+
+qemu doesn't boot Solaris 2.2
+Description of problem:
+Booting from the CDROM hangs
+Steps to reproduce:
+1. Run the command line above with a fresh disk image
+2. The console contains:
+```
+Trying cdrom:d...
+(is ?
+```
+3. No further progress
diff --git a/results/classifier/gemma3:12b/boot/1177 b/results/classifier/gemma3:12b/boot/1177
new file mode 100644
index 000000000..8663b2c39
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1177
@@ -0,0 +1,17 @@
+
+booting linux hangs with -cpu max or -cpu max,lpa2=off, but works with -cpu cortex-a57
+Description of problem:
+
+Steps to reproduce:
+1. Snag mini.iso from http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/mini.iso
+2. qemu-img create ubuntu-image.img 20G
+3. dd if=/dev/zero of=flash1.img bs=1M count=64
+4. dd if=/dev/zero of=flash0.img bs=1M count=64
+5. dd if=/home/imp/git/qemu/00-build/pc-bios/edk2-aarch64-code.fd of=flash0.img conv=notrunc
+6. Run the above command
+7. Select install, watch the kernel hang.
+8. Change -cpu max to -cpu cortex-a57 and it will work. -cpu max,lpa2=off also exhibits the problem
+Additional information:
+Just grabbed git and built it with ./configure in /home/imp/git/qemu/00-build.
+
+pm215 on irc suggested that it was an old EDK2 and a newer one is needed to cope with the newer CPU features in -cpu max
diff --git a/results/classifier/gemma3:12b/boot/1180923 b/results/classifier/gemma3:12b/boot/1180923
new file mode 100644
index 000000000..79988ef61
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1180923
@@ -0,0 +1,4 @@
+
+unused memory filled with 0x00 instead of 0xFF
+
+Qemu, ever since it was made (so, since 2003), has this problem in DOS (either PC-DOS or MS-DOS and partly Windows 9x) not recognizing the memory available when the memory is filled with 0x00 but when it is filled with 0xFF it gets recognized properly, where should I patch qemu to solve this memory problem?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1191326 b/results/classifier/gemma3:12b/boot/1191326
new file mode 100644
index 000000000..1d941c08f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1191326
@@ -0,0 +1,16 @@
+
+QNX 4 doesn't boot on qemu >= 1.3 
+
+
+I am using virtual machine with QNX4 operating system installed on it.  I updated my qemu from version
+to newer and QNX4 doesn't start any more. All is ok on version 1.2 but when I try to use any newer version 
+(1.3, 1.4, 1.5)  QNX4 doesn't boot.  I tried on windows and linux ubuntu hosts - effects are the same.
+
+When virtual machine boots qnx bootloader loads and starts operating system. In the next step
+qnx starts its ide driver, which detects qemu harddisk and cdrom. Problem starts when operating system
+tries mount partition - an error occur and qnx stop booting procedure:
+
+mount -p "No bios signature in partition sector on /dev/hd0"
+
+I have tried install qnx from cdrom but it seems that there is the same problem. QNX installer boot from
+cdrom, detects hard disk and cdrom, but cdrom can't be mounted in the next step of installation procedure.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1194954 b/results/classifier/gemma3:12b/boot/1194954
new file mode 100644
index 000000000..8ca7e71e3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1194954
@@ -0,0 +1,4 @@
+
+Windows 95 guest reboots itself on qemu 1.5.0 & 1.5.50 (GIT)
+
+When I begin to run a Windows 95 guest on these releases of qemu, it reboots itself more times without my permission (eg. without shutting it down properly), and when I'm installing Netscape 4.08 at, for example, 46% or 75%, it still reboots itself without completing the installation of the web browser. Is this an issue of main-loop.c?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1201 b/results/classifier/gemma3:12b/boot/1201
new file mode 100644
index 000000000..1c2888c6b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1201
@@ -0,0 +1,11 @@
+
+Qemu with Windows 10
+Description of problem:
+I see a colored screen with flashing cursor and cannot complete Windows installation.
+Steps to reproduce:
+1. Install `qemu-w64-setup-20220831.exe` on Windows 10 Pro for Workstations 21H2.
+2. `cd C:\Program Files\qemu`
+3. `qemu-img.exe create -f raw win.img 25600M`
+4. `qemu-system-i386w.exe -boot c -m 4096 -hda win.img -cdrom "C:\Users\me\Downloads\Win10_21H2_English_x64.iso"`
+Additional information:
+![xCeQH](/uploads/90a39994e020ffb174583fd3bafa520b/xCeQH.png)
diff --git a/results/classifier/gemma3:12b/boot/1230232 b/results/classifier/gemma3:12b/boot/1230232
new file mode 100644
index 000000000..5b4b461f1
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1230232
@@ -0,0 +1,34 @@
+
+mac99 does not find mac os x 10.4 dvd
+
+Hi there,
+
+I've compiled qemu 1.6.0 and ripped my Mac OS X 10.4 dvd to iso format.
+Now I'm trying to get qemu to boot the dvd and install the OS with:
+
+qemu-system-ppc64 -M mac99 -m 256 -cdrom ./tiger.iso -boot d -sdl -display sdl -net nic -net user -prom-env 'boot-args=-v' -cpu G4 -hda ./tiger.img
+
+It shows the grey apple logo for a few seconds and then I get the following boot prompt:
+-------------------------------------------------
+standard timeslicing quantum is 10000 us
+vm_page_bootstrap: 60198 free pages
+mig_table_max_displ = 70
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+                The Regents of the University of California. All rights reserved.
+
+using 655 buffer headers and 655 cluster IO buffer headers
+ApplePlatformExpert::getGMTTimeOfDay can not provide time of day RTC did not show up
+Security auditing service present
+BSM auditing present
+disabled
+rooting via boot-uuid from /chosen: 8ABB5AFF-FC7A-310A-9BFE-8A263F654562
+Waiting on <dict ID="0"><key>IOProviderClass</key><string ID="1">IOResources</string><key>IOResource
+Match</key><string ID="2">boot-uuid-media</string></dict>
+Still waiting for root device
+Still waiting for root device
+Still waiting for root device
+Still waiting for root device
+Still waiting for root device
+-------------------------------------------------
+
+It keeps repeating the "Still waiting for root device" ?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1246 b/results/classifier/gemma3:12b/boot/1246
new file mode 100644
index 000000000..cde3cfcf3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1246
@@ -0,0 +1,2 @@
+
+Win11_22H2_English_x64.iso won't boot
diff --git a/results/classifier/gemma3:12b/boot/1252 b/results/classifier/gemma3:12b/boot/1252
new file mode 100644
index 000000000..394ef8be8
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1252
@@ -0,0 +1,18 @@
+
+Debian Raspberry Pi images do not boot with version 7 and higher
+Description of problem:
+The Debian Bullseye RPi4 4GB image [here](https://raspi.debian.net/tested-images/) does not boot with versions 7 and higher, while it does boot with v6.2.0.  The Bookworm image works with v7.
+Steps to reproduce:
+0. `export DEB_VERS=5.10.0-11`
+1. `wget https://raspi.debian.net/tested/20220121_raspi_4_bullseye.img.xz`
+2. `dd if=/dev/null of=disk-$DEB_VERS.img bs=1M seek=10240`
+    * NB: This creates a 10 GB file 
+3. `xzcat $RPI_IMG | dd of=disk-$DEB_VERS.img conv=notrunc status=progress`
+4. `partx -a -v disk-$DEB_VERS.img`
+5. `mount /dev/loop0p1 /mnt`
+6. `cp /mnt/initrd.img-$DEB_VERS-arm64 .`
+7. `cp /mnt/vmlinuz-$DEB_VERS-arm64 .`
+8. `umount /mnt`
+9. `qemu-system-aarch64 -M virt -m 4096 -cpu max -drive format=raw,file=disk-$DEB_VERS.img -nographic -append "console=tty0 console=ttyAMA0,115200 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=64M rootwait" -initrd initrd.img-$DEB_VERS-arm64 -kernel vmlinuz-$DEB_VERS-arm64`
+Additional information:
+The URL for the image in step 1 has been known to change, so if you get a 404, go to the URL above and find the correct one.
diff --git a/results/classifier/gemma3:12b/boot/1259499 b/results/classifier/gemma3:12b/boot/1259499
new file mode 100644
index 000000000..1777e33cd
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1259499
@@ -0,0 +1,36 @@
+
+QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system-x86_64
+
+I have upgraded to QEmu 1.7.0 (Debian 1.7.0+dfsg-2) but now when I try to restore a live snapshot made in QEmu 1.6.0 (Debian 1.6.0+dfsg-1) I see that the VM boots from scratch instead of starting directly in the snapshot's running state.
+
+Furthermore if the VM is already running and I try to revert to the snapshot again I get the following message:
+
+$ virsh --connect qemu:///system snapshot-revert fgtbbuild wtb; echo $?
+error: operation failed: Error -22 while loading VM state
+1
+
+I have test VMs with live snapshots corresponding to different testing configurations. So I typically revert the VMs in one of the live snapshots and run the tests. It would be pretty annoying to have to recreate all these live snapshots any time I upgrade QEmu bug it looks like I'll have to do it again.
+
+This all sounds very much like bug 1123975 where QEmu 1.3 broke compatibility with previous versions live snapshots :-(
+
+Here is the command being run by libvirt:
+
+/usr/bin/qemu-system-x86_64 -name fgtbbuild -S -machine pc-1.1,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid f510955c-17de-9907-1e33-dfe1ef7a08b6 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fgtbbuild.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/storage1/qemu/fgtbbuild.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0a:3c:e8,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -loadvm wtb
+
+ipxe-qemu 1.0.0+git-20120202.f6840ba-3
+qemu 1.7.0+dfsg-2
+qemu-keymaps 1.7.0+dfsg-2
+qemu-slof 20130430+dfsg-1
+qemu-system 1.7.0+dfsg-2
+qemu-system-arm 1.7.0+dfsg-2
+qemu-system-common 1.7.0+dfsg-2
+qemu-system-mips 1.7.0+dfsg-2
+qemu-system-misc 1.7.0+dfsg-2
+qemu-system-ppc 1.7.0+dfsg-2
+qemu-system-sparc 1.7.0+dfsg-2
+qemu-system-x86 1.7.0+dfsg-2
+qemu-user 1.7.0+dfsg-2
+qemu-utils 1.7.0+dfsg-2
+libvirt-bin 1.1.4-2
+libvirt0 1.1.4-2
+libvirtodbc0 6.1.6+dfsg-4
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1260555 b/results/classifier/gemma3:12b/boot/1260555
new file mode 100644
index 000000000..41be0c80e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1260555
@@ -0,0 +1,17 @@
+
+SS-5 emulation doesn't work with Sun boot ROM
+
+
+The 32-bit SPARC emulator's TCX emulation seems to work with OpenBIOS, but doesn't work with a SparcStation ROM on Cocoa.  Screenshot attached.  Using version 1.7.0 on Mac OS X 10.9 via MacPorts and compiled directly from source, though this problem has carried over from Mac OS X 10.8 and many earlier versions of Qemu.
+
+The following is my Qemu command:
+
+sudo qemu-system-sparc -m 256 -M SS-5 -bios /home/img/ROMs/sun/ss5-170.bin \
+  -g 1024x768x24 \
+  -drive file=/home/doc/VMs/slagheap/sd0.raw,if=scsi,bus=0,unit=3 \
+  -drive file=/home/doc/VMs/slagheap/sd1.raw,if=scsi,bus=0,unit=1 \
+  -drive file=/home/doc/VMs/slagheap/sd2.raw,if=scsi,bus=0,unit=2 \
+  -net nic,macaddr=DE:EE:DD:FF:EE:DD,model=lance \
+  -net tap,ifname=tap0,script=/home/doc/VMs/slagheap/ifup,downscript=/home/doc/VMs/slagheap/ifdown
+
+Note: also can't compile Qemu w/ SDL support from MacPorts on Mac OS X, and config.log is not helpful to figure out why, but this is another issue.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1269 b/results/classifier/gemma3:12b/boot/1269
new file mode 100644
index 000000000..ddf9e1d76
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1269
@@ -0,0 +1,27 @@
+
+qemu-system-i386 no longer boots NetBSD
+Description of problem:
+Since qemu commit e3a79e0e87831602e41819591a8e6dcc70a2a231, NetBSD
+no longer boots under qemu-system-i386.
+Steps to reproduce:
+1. `wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/i386/installation/cdrom/boot-com.iso`
+2. `qemu-system-i386 -nographic -cdrom boot-com.iso`
+
+Expected behavior: the system boots and prompts you for a terminal type with
+
+    Terminal type (just hit ENTER for 'vt220'):
+
+Observed incorrect behavior: the guest kernel either hangs during boot at
+
+    Loading /stand/i386/9.2/modules/cd9660/cd9660.kmod  
+    WARNING: 1 module failed to load
+
+or panics during boot with
+
+    kernel: supervisor trap page fault, code=0
+    Stopped in pid 0.1 (system) at  netbsd:idt_vec_reserve+0xa:     cmpb    $0,netbs
+    d:idt_allocmap(%ebx)
+    db{0}>
+Additional information:
+This regression is a critical issue to the NetBSD project as its automated
+testing infrastructure is heavily dependent on qemu-system-i386.
diff --git a/results/classifier/gemma3:12b/boot/1272796 b/results/classifier/gemma3:12b/boot/1272796
new file mode 100644
index 000000000..4546ef38a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1272796
@@ -0,0 +1,20 @@
+
+Windows 98 First Edition emulation problems
+
+System: Debian SID x86 with latest updates
+
+1) QEMU compiled from latest main GIT branch (and 1.7 stable version)
+./configure options: ./configure --enable-sdl --target-list=i386-softmmu --cpu=i686 --audio-drv-list=alsa
+
+When you try to boot Windows 98 First Edition (Italian), it does not simply boot. It stays on booting screen. 
+If you try to install, the installation goes flawless, but when it boots it freeze.
+
+I am launching VM with this: qemu-system-i386 -hda main.img -cpu pentium -m 256 -fda floppy1.img -boot c -soundhw gus -vga cirrus
+
+I have tried with -M option "pc-i440fx-1.6" since 1.6 have no problems with the booting of Win98, but nothing. No fix found.
+
+2) QEMU 1.6.2 (same compile and launching options)
+gus soundboard seems not recognized even with real dos drivers (tried to install theme into real dos mode).
+with SoundBlaster 16 i have following error: WARNING: I/O thread spun for 1000 iterations, making the emulation impossible (too slow, and sound is stuttering) . Tried to compile with oss and sdl option on audio-drv-list but no fix found.
+
+Any ideas? thank you
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1273944 b/results/classifier/gemma3:12b/boot/1273944
new file mode 100644
index 000000000..b602f48e3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1273944
@@ -0,0 +1,12 @@
+
+multiboot header has 0 in mem_upper field
+
+When booting a multiboot image,. mem_upper is now always zero.
+
+To test, build qemu from current git head, then do
+  cd tests/multiboot
+  ./run_test.sh
+
+You will see the test fail.  In each case mem_upper is 0k.
+
+git-bisect says the bad commit is 0169c511554cb0014a00290b0d3d26c31a49818f in qemu.git
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1293 b/results/classifier/gemma3:12b/boot/1293
new file mode 100644
index 000000000..33c5b09b9
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1293
@@ -0,0 +1,2 @@
+
+Trusted Firmware stopped booting on SBSA-ref
diff --git a/results/classifier/gemma3:12b/boot/1294 b/results/classifier/gemma3:12b/boot/1294
new file mode 100644
index 000000000..64ba4532a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1294
@@ -0,0 +1,2 @@
+
+pflash size check appears to be incompatible with OVMF on x86
diff --git a/results/classifier/gemma3:12b/boot/1306 b/results/classifier/gemma3:12b/boot/1306
new file mode 100644
index 000000000..f7f77076f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1306
@@ -0,0 +1,160 @@
+
+OpenIndiana fails with "BAD TRAP" & "Page fault" in guest with SATA optical drive
+Additional information:
+I am not experienced in QEMU, and have not been able to isolate with a simple command line. However, I will attempt any test cases provided by the community.
+
+The problem in the domain reproduced below resolves by removing the SATA optical drive (even if the SATA controller remains).
+
+The working case may be derived through the following patch:
+
+```
+1c1
+< <domain type='kvm' id='83'>
+---
+> <domain type='kvm' id='82'>
+18a19
+>     <boot dev='hd'/>
+42c43
+<       <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='2'/>
+---
+>       <source file='/srv/store/epl/img/OI-hipster-minimal-20211031.iso' index='1'/>
+46d46
+<       <boot order='1'/>
+48,54d47
+<       <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+<     </disk>
+<     <disk type='file' device='cdrom'>
+<       <driver name='qemu'/>
+<       <target dev='sda' bus='sata'/>
+<       <readonly/>
+<       <alias name='sata0-0-0'/>
+```
+
+For consistency, the boot media is installed on an IDE optical drive, which appears not to cause problems. The problem was originally discovered attempting to boot from a SATA optical drive, following the intended layout of the guest system.
+
+---
+
+```
+<domain type='kvm' id='84'>
+  <name>openindiana-clone</name>
+  <uuid>7a0550ec-ff03-4894-80b8-affe0dfd8177</uuid>
+  <metadata>
+    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
+      <libosinfo:os id="http://oracle.com/solaris/11"/>
+    </libosinfo:libosinfo>
+  </metadata>
+  <memory unit='KiB'>2097152</memory>
+  <currentMemory unit='KiB'>2097152</currentMemory>
+  <vcpu placement='static'>4</vcpu>
+  <resource>
+    <partition>/machine</partition>
+  </resource>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-jammy'>hvm</type>
+    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
+    <nvram template='/usr/share/OVMF/OVMF_VARS_4M.fd'>/var/lib/libvirt/qemu/nvram/openindiana-clone_VARS.fd</nvram>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <vmport state='off'/>
+  </features>
+  <cpu mode='host-passthrough' check='none' migratable='on'/>
+  <clock offset='utc'>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <pm>
+    <suspend-to-mem enabled='no'/>
+    <suspend-to-disk enabled='no'/>
+  </pm>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu' type='raw'/>
+      <source file='/srv/img/OI-hipster-minimal-20211031.iso' index='2'/>
+      <backingStore/>
+      <target dev='hda' bus='ide'/>
+      <readonly/>
+      <boot order='1'/>
+      <alias name='ide0-0-0'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu'/>
+      <target dev='sda' bus='sata'/>
+      <readonly/>
+      <alias name='sata0-0-0'/>
+      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+    </disk>
+    <controller type='usb' index='0' model='ich9-ehci1'>
+      <alias name='usb'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci1'>
+      <alias name='usb'/>
+      <master startport='0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci2'>
+      <alias name='usb'/>
+      <master startport='2'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci3'>
+      <alias name='usb'/>
+      <master startport='4'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'>
+      <alias name='pci.0'/>
+    </controller>
+    <controller type='ide' index='0'>
+      <alias name='ide'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <controller type='sata' index='0'>
+      <alias name='sata0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </controller>
+    <input type='mouse' bus='ps2'>
+      <alias name='input0'/>
+    </input>
+    <input type='keyboard' bus='ps2'>
+      <alias name='input1'/>
+    </input>
+    <graphics type='spice'>
+      <listen type='none'/>
+      <image compression='off'/>
+      <gl enable='no'/>
+    </graphics>
+    <audio id='1' type='spice'/>
+    <video>
+      <model type='vga' vram='16384' heads='1' primary='yes'/>
+      <alias name='video0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <memballoon model='virtio'>
+      <alias name='balloon0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </memballoon>
+  </devices>
+  <seclabel type='dynamic' model='apparmor' relabel='yes'>
+    <label>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</label>
+    <imagelabel>libvirt-7a0550ec-ff03-4894-80b8-affe0dfd8177</imagelabel>
+  </seclabel>
+  <seclabel type='dynamic' model='dac' relabel='yes'>
+    <label>+64055:+130</label>
+    <imagelabel>+64055:+130</imagelabel>
+  </seclabel>
+</domain>
+```
+
+
+---
+
+![Screenshot_openindiana-clone_2022-11-07_11_24_06](/uploads/2f4a22d0fe3d5e2eb689bbaeb6dce346/Screenshot_openindiana-clone_2022-11-07_11_24_06.png)
diff --git a/results/classifier/gemma3:12b/boot/1310324 b/results/classifier/gemma3:12b/boot/1310324
new file mode 100644
index 000000000..b04b8f8cd
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1310324
@@ -0,0 +1,22 @@
+
+Commit 0f842f8a introduces regression when using tcg-interpreter
+
+Hi.
+
+Commit 0f842f8a246f2b5b51a11c13f933bf7a90ae8e96 apparently introduces a regression when using --enable-tcg-interpreter. The regression is manifested as follows:
+
+ 1. Checkout any qemu commit later or equal that the one said above. Beside that one, I tested v1.7.1, v2.0.0 and a few other commits suggested to my by git bisect.
+ 2. Possibly cherry-pick commit a32b12741bf45bf3f46bffe5a79cb2548a060cd8, which fixes a compilation bug with --enable-tcg-interpreter.
+ 3. Compile with: ./configure --target-list=i386-softmmu --enable-tcg-interpreter && make -j8
+ 4. Create an empty virtual disk and try to install Windows XP on it booting from Windows CD-ROM. After the loading program, the installer immediately crashes with blue screen (it should instead show the installation confirmation dialog and then the EULA acceptance dialog, if it worked correctly).
+
+I'm mentioning Windows XP because it is the problem I found. Probably other operating systems would fail as well. I can test others, if you think it would be helpful. I can also give you access to the very exact CD-ROM image I'm using.
+
+The exact command line I'm using is:
+build_location/i386-softmmu/qemu-system-i386 -m 512 -drive file=winxp_test.img -cdrom wipxp_cdrom.iso
+
+Attached is the blue screen that I see (unfortunately it is Italian, but that's a standard error message and I hope this is not a problem).
+
+I'm not able to understand the nature of the commit to identify what could be the problem. My nose tells me that it may be some stupid mistake, for example in some offset constant, that nobody ever saw because tcg-interpreter is not much used.
+
+Thanks, Giovanni.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1314667 b/results/classifier/gemma3:12b/boot/1314667
new file mode 100644
index 000000000..5305b75ca
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1314667
@@ -0,0 +1,45 @@
+
+PMPrebUSB - appcrash of qemu in Win-7-64bit
+
+I am not sure if this issue is a bug of qemu or by Win-7.
+I want to test in advance with QEMU the ability if my USB-Rescue-Drive is 
+booting correctly. I have Win-7-64 and run qemu v.o.15.1.0 out of the installed RMPrepUSB v.2.1.719 
+program. The settings for the preparation of my USB drive were FAT32 boot as
+HD, bootloader WinPE/Win-7/Vista, set for running iso-files directly in %_ISO
+\MAINMENU\Hiren’sBootCD.iso. When I run Qemu I get the messages in the cmd starting window it says:
+
+Administrator: RMPrepUSB QEMU Launcher
+**************************************
+EXECUTING "C:\Program Files (x86)\RMPrepUSB\qemu\STARTFROMUSB.cmd"
+DRIVE NUMBER=3
+MEMORY SIZE=1000
+HARD DISK IMAGE=harddisk.img
+NOWRITE=
+Found OS=VISTA_OR_LATER
+Sending command Start_VM.exe 3 500 qemu.exe -L . -name "RMPrepUSB Emulation 
+Session  RAM=1000MB VirtualHDD=harddisk.i
+lt+LCtrl)" -boot c -m 1000 -drive file=\\.
+\PhysicalDrive3,if=ide,index=0,media=disk -hdb harddisk.img to shell...
+
+Win-7: in the second window appears:
+***********************************
+-->qemu funktioniert nicht mehr
+Problemsignatur:
+  Problemereignisname:	APPCRASH
+  Anwendungsname:	qemu.exe
+  Anwendungsversion:	0.15.1.0
+  Anwendungszeitstempel:	4f478c16
+  Fehlermodulname:	qemu.exe
+  Fehlermodulversion:	0.15.1.0
+  Fehlermodulzeitstempel:	4f478c16
+  Ausnahmecode:	40000015
+  Ausnahmeoffset:	00053b06
+  Betriebsystemversion:	6.1.7601.2.1.0.256.48
+  Gebietsschema-ID:	1031
+  Zusatzinformation 1:	bf8d
+  Zusatzinformation 2:	bf8d49108a2e5a0707fc48438e01652a
+  Zusatzinformation 3:	b0f1
+  Zusatzinformation 4:	b0f155b0f1de9c5eb22bd6d100737cbe
+
+If somebody can understand that behaviour I appreciate everybodies help. Thank you with regards
+H.O.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1320 b/results/classifier/gemma3:12b/boot/1320
new file mode 100644
index 000000000..c66fdf89f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1320
@@ -0,0 +1,13 @@
+
+qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin"
+Description of problem:
+qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin"
+Steps to reproduce:
+1. wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.79.tar.xz
+2. sudo apt-get install crossbuild-essential-riscv64
+3. make ARCH=riscv defconfig && make ARCH=riscv menuconfig 
+4. make -j4 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- 
+5. trucate -s 128G rootfs.img && mkfs.ext4 rootfs.img
+6. sudo mount -o loop ./rootfs.img /mnt
+7. debootstrap --arch=riscv64 focal /mnt
+8. qemu-system-riscv64 -machine virt -bios default -m 512M -kernel ./linux-5.15.79/arch/riscv/boot/Image -drive file=./rootfs.img,format=raw
diff --git a/results/classifier/gemma3:12b/boot/1324 b/results/classifier/gemma3:12b/boot/1324
new file mode 100644
index 000000000..65b1d5dd3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1324
@@ -0,0 +1,41 @@
+
+Unhandled exception when booting UEFI x86_64 system image
+Description of problem:
+I have a bootable Ubuntu 20.04-based operating system image that I typically flash to the internal storage of an embedded Intel Atom computer. When I try booting it under QEMU, I reach the GRUB boot menu, but when it attempts to start the kernel, it outputs:
+
+```
+ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached
+Bail out! ERROR:../target/i386/tcg/sysemu/excp_helper.c:517:raise_stage2: code should not be reached
+Aborted (core dumped)
+``` 
+
+The kernel settings configured in GRUB are:
+
+```
+linux         /boot/vmlinuz-5.4.0-132-generic root=UUID=816fe083-fc26-4a0d-ae4a-68d1b16dfb66 ro console=uart,mmio32,0xd091c000 console=ttyS4,115200n8 console=tty0                                                         ?
+initrd        /boot/initrd.img-5.4.0-132-generic 
+```
+
+If I run an older QEMU 4.2.1 that ships with Ubuntu:
+
+```
+!!!! X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 00000000 !!!!
+ExceptionData - 0000000000000000
+RIP  - 0000000007F2CD0E, CS  - 0000000000000038, RFLAGS - 0000000000200206
+RAX  - AFAFAFAFAFAFAFAF, RCX - 000000000657F408, RDX - AFAFAFAFAFAFAFAF
+RBX  - 0000000000000288, RSP - 0000000007F1BC48, RBP - 0000000007F336A0
+RSI  - 0000000007F336F8, RDI - 0000000000001000
+R8   - 000000000657F408, R9  - 0000000000000320, R10 - 0000000000000000
+R11  - 0000000000000000, R12 - 0000000000000004, R13 - 000000000657F400
+R14  - 0000000000000000, R15 - 0000000000000000
+DS   - 0000000000000030, ES  - 0000000000000030, FS  - 0000000000000030
+GS   - 0000000000000030, SS  - 0000000000000030
+CR0  - 0000000080010033, CR2 - 0000000000000000, CR3 - 0000000007C01000
+CR4  - 0000000000000668, CR8 - 0000000000000000
+DR0  - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
+DR3  - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
+GDTR - 0000000007BEEA98 0000000000000047, LDTR - 0000000000000000
+IDTR - 00000000072D1018 0000000000000FFF,   TR - 0000000000000000
+FXSAVE_STATE - 0000000007F1B8A0
+!!!! Find image based on IP(0x7F2CD0E) /build/edk2-xUnmxG/edk2-0~20191122.bd85bf54/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll (ImageBase=0000000007F1D000, EntryPoint=0000000007F2FAAE) !!!!
+```
diff --git a/results/classifier/gemma3:12b/boot/1328 b/results/classifier/gemma3:12b/boot/1328
new file mode 100644
index 000000000..c91ed2cf5
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1328
@@ -0,0 +1,10 @@
+
+Cannot boot any UEFI systems after upgrade edk2-ovmf
+Description of problem:
+After upgrading edk2-ovmf from version 202208-1 to version 202208-3 none of my virtual machines on UEFI (windows and Arch linuw guest) have successfully started.
+
+I'm using Virtual Manager and virt-viewer with virsh.
+Steps to reproduce:
+1. Update edk2-ovmf to 202208-3
+2. Restart all running VM
+3. Vm with UEFI bios cannot boot
diff --git a/results/classifier/gemma3:12b/boot/1342686 b/results/classifier/gemma3:12b/boot/1342686
new file mode 100644
index 000000000..403acef0a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1342686
@@ -0,0 +1,15 @@
+
+Windows 95 setup hangs
+
+Windows 95 (first version, not 95A or OSR2) setup hangs on QEMU version 2.0.0. It was compiled from the sources on Fedora 20. 
+Setup starts without problems, it goes through the first phase and then hangs on the "Getting ready to run Windows 95 for the first time..." screen (http://www.guidebookgallery.org/screenshots/win95#win95startupshutdownsplash1correctaspect).
+
+Steps to reproduce:
+qemu-img create -f qcow2 win95.img 2G
+qemu -L . -machine isapc -cpu pentium -m 32 -vga std -soundhw sb16 -hda win95.img -cdrom POLWIN95.ISO -fda BOOT95A.IMA -boot a
+after this select default options everywhere. When it asks to remove the boot floppy do "eject floppy0" and confirm.
+It displays the "Getting ready to run Windows 95 for the first time..." and hangs.
+
+The same behavior can be observed on 2.1.0-rc2. On 1.7.1 It hangs immediately after this screen, it hangs on displaying a underscore cursor.
+
+I managed to complete the setup on QEMU 1.6.2.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1348 b/results/classifier/gemma3:12b/boot/1348
new file mode 100644
index 000000000..ed1e9605f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1348
@@ -0,0 +1,2 @@
+
+WIN10 MBR/SeaBIOS/CSM machine hangs at boot (same as  #1115  https://gitlab.com/qemu-project/qemu/-/issues/1115 )
diff --git a/results/classifier/gemma3:12b/boot/1363467 b/results/classifier/gemma3:12b/boot/1363467
new file mode 100644
index 000000000..c2cdb0284
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1363467
@@ -0,0 +1,11 @@
+
+qemu-system-i386 does not work
+
+I am using QEMU 2.1.0 on a Slackware 14.1 operating system (with Linux 3.15.8).
+
+I run QEMU like this:
+$ qemu-system-i386 slackware-14.1-install-dvd.iso
+I have also tested with the "-enable-kvm" and the "-m 1000" options.
+
+And QEMU is does not work.
+I mean, after 10 minutes, nothing is displayed on the screen, I am not able to see the Slackware installer.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1381639 b/results/classifier/gemma3:12b/boot/1381639
new file mode 100644
index 000000000..fd654b9a8
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1381639
@@ -0,0 +1,16 @@
+
+sys_eeprom.c:353: buffer too small
+
+[qemu-2.1.2/roms/u-boot/board/matrix_vision/mvblx/sys_eeprom.c:353]: (error) Buffer is accessed out of bounds.
+
+        char ethaddr[9];
+
+        sprintf(ethaddr, "%02X:%02X:%02X:%02X:%02X:%02X",
+            e.mac[0],
+            e.mac[1],
+            e.mac[2],
+            e.mac[3],
+            e.mac[4],
+            e.mac[5]);
+
+18 into 9 won't go. Suggest increase size of ethaddr.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1381642 b/results/classifier/gemma3:12b/boot/1381642
new file mode 100644
index 000000000..de1b351b3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1381642
@@ -0,0 +1,13 @@
+
+ecovec.c:66: buffer too small by one.
+
+[qemu-2.1.2/roms/u-boot/board/renesas/ecovec/ecovec.c:66]: (error) Buffer is accessed out of bounds.
+
+    sprintf(env_mac, "%02X:%02X:%02X:%02X:%02X:%02X",
+        mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
+
+but
+
+    char env_mac[17];
+
+and 18 into 17 won't go. Suggest increase size of env_mac.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1389 b/results/classifier/gemma3:12b/boot/1389
new file mode 100644
index 000000000..830fd6651
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1389
@@ -0,0 +1,62 @@
+
+Qemu 7.2.0 My hobbby bootloader seemed to stop working
+Description of problem:
+I wrote a BIOS bootloader and OS, but updated to QEMU 7.2.0 and now I get an exception in my bootloader.
+Specifically I am getting a page fault on the first line of map_pd:
+```
+next_pdpt:
+    ; PDPT
+    mov [0xa000 + rdx * 8], rax ; PDPT[rdx] -> PD
+    and al, 0xfc ;; clear bits 1 and 2
+
+    mov rcx, 0
+map_pd:
+    mov [rax + rcx * 8], rdi ; PD[rcx] -> rax
+    add rdi, 0x200000 ; maps first 512 * 0x200000 or 1 GiB
+    sub rsi, 1
+    cmp rsi, 0
+    je done_map_rest
+
+    add rcx, 1
+    cmp rcx, 512
+    jb map_pd
+
+    add rdx, 1 ; do next GiB
+    add rax, 0x1000 ; next PD
+    or rax, (1 | 2)
+
+    jmp next_pdpt
+```
+I am getting the exception:
+```
+check_exception old: 0xffffffff new 0xe
+     0: v=0e e=0002 i=0 cpl=0 IP=0008:0000000000001311 pc=0000000000001311 SP=0010:0000000000007bf8 CR2=000000000020c000
+RAX=000000000020c000 RBX=00000000000b8040 RCX=0000000000000000 RDX=0000000000000201
+RSI=000000000003fe00 RDI=0000008040000083 RBP=0000000000000008 RSP=0000000000007bf8
+R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000
+R12=0000000000000000 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000
+RIP=0000000000001311 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+CS =0008 0000000000000000 00000000 00209a00 DPL=0 CS64 [-R-]
+SS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+DS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+FS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+GS =0010 0000000000000000 00000000 00009300 DPL=0 DS   [-WA]
+LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
+TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
+GDT=     0000000000001888 00000018
+IDT=     0000000090909000 00000000
+CR0=80000011 CR2=000000000020c000 CR3=0000000000009000 CR4=00000020
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+CCS=0000000000000200 CCD=0000000000000000 CCO=LOGICB
+EFER=0000000000000500
+```
+
+I am able to read the 0x20c000 address with gdb
+Steps to reproduce:
+1. clone and build https://github.com/darbysauter/myOS
+2. run with `make run` on 7.0.0
+3. run with `make run` on 7.2.0 and there is an exception
+Additional information:
+I looked through the changelogs from 7.1 and 7.2 and nothing stood out to me. Not sure if some behaviour changed or some default changed.
diff --git a/results/classifier/gemma3:12b/boot/1415181 b/results/classifier/gemma3:12b/boot/1415181
new file mode 100644
index 000000000..d22cf2679
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1415181
@@ -0,0 +1,5 @@
+
+Access raw partitions from Windows
+
+I'm using a windows tablet that makes imposible usb booting. It would be nice to have access to raw partitions in order to run linux installers using qemu. I can successfully install several boot loaders using uefi, so I gues this feature would be very helpful.
+Thanks!
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1426472 b/results/classifier/gemma3:12b/boot/1426472
new file mode 100644
index 000000000..603d4554c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1426472
@@ -0,0 +1,28 @@
+
+Recent regression: segfault on startup with -snapshot
+
+As of git revision 041ccc922ee474693a2869d4e3b59e920c739bc0, qemu segfaults on startup when I try to boot a hard disk image with the -snapshot option.
+
+To reproduce:
+
+  wget http://wiki.qemu.org/download/linux-0.2.img.bz2
+  bunzip2 linux-0.2.img.bz2 
+  qemu-system-i386 -hda linux-0.2.img -snapshot
+
+When I run this, qemu-system-i386 crashes with a segmentation fault. This is on a Debian 7 amd64 host.
+
+git bisect implicates the following commit:
+
+commit a464982499b2f637f6699e3d03e0a9d2e0b5288b
+Author: Paolo Bonzini <email address hidden>
+Date:   Wed Feb 11 17:15:18 2015 +0100
+
+    rcu: run RCU callbacks under the BQL
+
+    This needs to go away sooner or later, but one complication is the
+    complex VFIO data structures that are modified in instance_finalize.
+    Take a shortcut for now.
+
+    Reviewed-by: Michael Roth <email address hidden>
+    Tested-by: Michael Roth <email address hidden>
+    Signed-off-by: Paolo Bonzini <email address hidden>
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1429841 b/results/classifier/gemma3:12b/boot/1429841
new file mode 100644
index 000000000..243d5ec58
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1429841
@@ -0,0 +1,47 @@
+
+error "rom: requested regions overlap" for NOLOAD sections
+
+command line:
+qemu-system-arm -semihosting -nographic -monitor null -serial null -no-reboot -kernel build/fw/0HNFcomSLuP1_CUNIT.elf
+
+output:
+rom: requested regions overlap (rom phdr #6: build/fw/0HNFcomSLuP1_CUNIT.elf. free=0x8001effc, addr=0x8001c000)
+rom loading failed
+
+I checked the sections of the .elf file with arm-none-eabi-objdump -h:
+Sections:
+Idx Name          Size      VMA       LMA       File off  Algn
+...
+ 35 .marker_appli 00001000  801ae000  801ae000  00025000  2**0
+                  ALLOC
+ 36 .safe_data    00000014  80200000  8001b000  00020000  2**2
+                  CONTENTS, ALLOC, LOAD, DATA
+ 37 .safe_bss     00000488  80200020  8001b020  00020014  2**2
+                  ALLOC
+ 38 .marker_safe_data 00001000  80201000  8001c000  00029000  2**0
+                  ALLOC
+ 39 .data         000008cc  80202000  8001b600  00022000  2**3
+                  CONTENTS, ALLOC, LOAD, DATA
+ 40 .bss          0000312c  802028d0  8001bed0  000228cc  2**3
+                  ALLOC
+ 41 .marker_data  00001000  80206000  8001f600  00026000  2**0
+                  ALLOC
+ 42 .cunit        00010000  80300000  80119600  00028000  2**0
+                  ALLOC
+ 43 .marker_code  00001000  8001c000  8001c000  00024000  2**0
+                  ALLOC
+...
+
+So I had a look where the values in  the error message could come from:
+0x8001c000: is the "LMA" value of section .marker_safe_data
+0x8001effc: is "Size" + "LMA" of the .bss section (0x0000312c + 0x8001bed0)
+
+So it is correct that (regarding the "LMA" value) the .marker_safe_data section collides with .bss section.
+But actually these sections have no "LOAD" attribute, so I would guess that their "LMA" should not be used anyway.
+Those section should reside at their "VMA" addresses (0x802xxxxx) during runtime but they have no data to load.
+
+Or am I getting something completely wrong?
+Should I give an additional option to qemu?
+
+I got this error with 2.0.0+dfsg-2ubuntu1.10 and 1.0.50-2012.03-0ubuntu2.1
+I didn't get this error (but others) with 0.10.2
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1435101 b/results/classifier/gemma3:12b/boot/1435101
new file mode 100644
index 000000000..ea0ed9af3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1435101
@@ -0,0 +1,6 @@
+
+Windows, QEMU 2.2.50 fails to boot XP CD
+
+Running XP Pro SP3 host 32bit.  When I launch qemu booting from CD, it fails to complete load, getting stuck at "Setup is starting Windows". It does not proceed past. I tried to disable floppy but still no go. Download older version 1.5.1-win32, 0.9.1, same problem. 
+qemu-system-i386w.exe -cdrom "d:\XP.ISO" -hda d:\xp.img -boot d 
+with -global isa-fdc.driveA=c or -no-fd-bootchk switches but no go. I see others have run into this problem as well but no real solutions. Some folks says turning off floppy works and I tried.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1437 b/results/classifier/gemma3:12b/boot/1437
new file mode 100644
index 000000000..a82cb8952
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1437
@@ -0,0 +1,7 @@
+
+Nitrux doesn't finish boot process
+Description of problem:
+Boot process doesn't finish
+![imagen](/uploads/787a61359bb79ba644a7d99bf021680e/imagen.png)
+Steps to reproduce:
+1.Load Nitrux ISO
diff --git a/results/classifier/gemma3:12b/boot/1447 b/results/classifier/gemma3:12b/boot/1447
new file mode 100644
index 000000000..11a1d1140
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1447
@@ -0,0 +1,8 @@
+
+riscv: reset_vec uses CSR even when disabled causing inability to boot
+Steps to reproduce:
+1. Run any rv32 binary with `./qemu-system-riscv32 -cpu rv32,d=off,f=off,Zicsr=off`
+
+To view using GDB use `./qemu-system-riscv32 -cpu rv32,d=off,f=off,Zicsr=off -S -s`
+`gdb-multiarch --ex="target remote localhost:1234" -ex "layout asm"`
+then type `si` till $pc jumps to zero on `csrr   a0, mhartid`
diff --git a/results/classifier/gemma3:12b/boot/147 b/results/classifier/gemma3:12b/boot/147
new file mode 100644
index 000000000..1ba41df59
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/147
@@ -0,0 +1,2 @@
+
+Interacting with NetBSD serial console boot blocks no longer works
diff --git a/results/classifier/gemma3:12b/boot/1473451 b/results/classifier/gemma3:12b/boot/1473451
new file mode 100644
index 000000000..4c2be2ae8
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1473451
@@ -0,0 +1,10 @@
+
+Please support the native bios format for dec alpha
+
+Currently qemu-system-alpha -bios parameter takes an ELF image.
+However HP maintains firmware updates for those systems.
+
+Some example rom files can be found here ftp://ftp.hp.com/pub/alphaserver/firmware/current_platforms/v7.3_release/DS20_DS20e/
+
+It might allow things like using the SRM firmware.
+The ARC(nt) firmware would allow to build and test windows applications for that platforms without having the relevant hardware
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1476800 b/results/classifier/gemma3:12b/boot/1476800
new file mode 100644
index 000000000..8c4a3e6ba
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1476800
@@ -0,0 +1,4 @@
+
+Instant runtime error (Host: Windows 8.1 VM: WinXP ISO)
+
+I have Qemu Manager on my Windows 8.1 laptop and have a WXP iso and a blank disk image (from here http://www.mediafire.com/download/rtec86bwwmee00s/Blank_Disk.zip ) and as soon as I try to open it I get a Runtime Error ( http://i.gyazo.com/bfebf7e1e7a670f8e52cc95c5923a67e.png )
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1481750 b/results/classifier/gemma3:12b/boot/1481750
new file mode 100644
index 000000000..9029b3f91
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1481750
@@ -0,0 +1,19 @@
+
+qemu-system-ppc hangs when running  -M ppce500 -bios u-boot.e500
+
+On recent qemu versions (tested on locally built versions 2.3.50 and 2.3.93)
+the command below causes qemu to hang before the u-boot command prompt is reached.
+However in an older version (2.2.1) the u-boot bootprompt is reached and can be typed into,
+so apparenly something has broken along the way.
+
+
+ppc-softmmu/qemu-system-ppc -d guest_errors -d in_asm -M ppce500 -nographic -bios pc-bios/u-boot.e500
+
+
+From the -d in_asm argument you can compare the runs and the 2.2.1 version
+outputs a lot more.
+
+------
+- I use the unmodified u-boot.e500 that is inlcuded with each respective version.
+- when building qemu my configure paramters were in all three cases :
+'./configure' '--target-list=ppc-softmmu,arm-softmmu' '--audio-drv-list=' '--enable-debug'
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1487 b/results/classifier/gemma3:12b/boot/1487
new file mode 100644
index 000000000..a7026deb5
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1487
@@ -0,0 +1,6 @@
+
+Mac OS X 10.4-10.6 i386/x86_64 not working on Apple Silicon
+Description of problem:
+Mac OS X panics early in the boot process. There are no issues using later versions of macOS or the PPC architecture
+Steps to reproduce:
+1. trying to boot 10.4/10.5/10.6 using i368/x86_64 emulation on apple silicon
diff --git a/results/classifier/gemma3:12b/boot/1496712 b/results/classifier/gemma3:12b/boot/1496712
new file mode 100644
index 000000000..b6d9f20b8
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1496712
@@ -0,0 +1,35 @@
+
+no bootable device after qemu-img convert parallels windows 2012 r2 to raw/qcow2 
+
+Hello
+We have converted a parallels windows 2012 R2 image with the command
+qemu-img convert -p -f parallels -O raw ./TestLibvirt.pvm/TestLibvirtMig-0.hdd/TestLibvirtMig-0.hdd.0.hds /var/lib/libvirt/images/testlibvirtmig.raw
+
+Afterthat we have created a new entry with virtual machine manager and used this raw-hdd file as "import existing disk image"
+
+Then we booted this virtual server and we got the error 
+"Booting from Hard Disk"
+"no Bootable device"
+
+Test 1: we also tried to "overwrite" the windows server drive
+1. Create a vm with windows 2012 r2 (W2K12R2) with virtual machine manager. Which runs good
+2. Then we mounted in the command line the "no bootable device" server  as source (raw image)
+    mount /ev/mapper/loop0p4 /mnt/source
+3. Then we mounted the new created (W2K12R2) as target (raw image)
+    mount /ev/mapper/loop1p2 /mnt/target
+4. with the copy command we have overwritten all files on the windows drive
+    rsync -av --delete /mnt/source/* /mnt/target/ 
+5. reboot the server and we have a blue screen and it tells me something prl_strg.sys 
+     "your PC ran into a problem and needs to restart ...... If you'd like to know more, you can search online later for this error: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(prl_strg.sys)
+
+Test 2: We also did a qemu-img convert from an ubuntu 14.04 disk and this works perfect.
+
+Thanks a lot
+Moritz
+
+PS: Installation of Host-Server uses: ubuntu vivid 15.04 with
+qemu-system     1:2.2+dfsg-5expubuntu9.4
+libvirt-bin     1.2.12-0ubuntu14.2
+libvirt-glib-1.0-0      0.1.9-4
+libvirt0        1.2.12-0ubuntu14.2
+virt-manager    1:1.0.1-5ubuntu1
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1498144 b/results/classifier/gemma3:12b/boot/1498144
new file mode 100644
index 000000000..cec02914b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1498144
@@ -0,0 +1,30 @@
+
+ Failure booting hurd with qemu-system-i386 on ARM
+
+Trying to boot debian-hurd-20150320.img ends with:
+
+qemu-system-i386: qemu-coroutine-lock.c:91: qemu_co_queue_restart_all: Assertion `qemu_in_coroutine()' failed.
+
+Program received signal SIGABRT, Aborted.
+__libc_do_syscall ()
+    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
+44      ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
+(gdb) bt
+#0  __libc_do_syscall ()
+    at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
+#1  0xb6ef8f0e in __GI_raise (sig=sig@entry=6)
+    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
+#2  0xb6efb766 in __GI_abort () at abort.c:89
+#3  0xb6ef4150 in __assert_fail_base (
+    fmt=0x1 <error: Cannot access memory at address 0x1>, 
+    assertion=0x7f89a234 "qemu_in_coroutine()", assertion@entry=0x0, 
+    file=0x7f89da58 "qemu-coroutine-lock.c", file@entry=0xb5660000 "\001", 
+    line=91, line@entry=3069931692, 
+    function=function@entry=0x7f89ab78 "qemu_co_queue_restart_all")
+    at assert.c:92
+#4  0xb6ef41e6 in __GI___assert_fail (assertion=0x0, file=0xb5660000 "\001", 
+    line=3069931692, function=0x7f89ab78 "qemu_co_queue_restart_all")
+    at assert.c:101
+#5  0x7f59a6b4 in ?? ()
+
+I was using the same setup as in Bug 893208 (i.e git checkout from 2015-09-15)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1512134 b/results/classifier/gemma3:12b/boot/1512134
new file mode 100644
index 000000000..b2db69a1f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1512134
@@ -0,0 +1,29 @@
+
+Multiboot v1 memory map offset wrong
+
+I'm developping a multiboot kernel for multiboot v1
+My multiboot header contains the V1 magic (0x1BADB002) and the flags 0x00010243  (with enabled memory detection, and boot loader name)
+
+
+When booted in multiboot,
+Qemu gives me two pointers:
+unsigned long mmap_length;
+unsigned long mmap_addr;
+
+mmap_addr shall points to this structure:
+struct multiboot_mmap_entry
+{
+multiboot_uint32_t size;
+multiboot_uint64_t addr;
+multiboot_uint64_t len;
+multiboot_uint32_t type;
+} 
+
+
+According to the multiboot v1 specification, mmap_addr should not point  to the start of this structure, but instead, should point to the "addr "field.
+
+Work-arround:
+Detect if qemu is used using bootloader_name field.
+If it is, do NOT apply a -4 offset to mmap_addr
+
+http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1516 b/results/classifier/gemma3:12b/boot/1516
new file mode 100644
index 000000000..d267e8ed4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1516
@@ -0,0 +1,40 @@
+
+QEMU does not reload kernel image on guest reboot (direct kernel boot)
+Description of problem:
+I am using virtiofs as root filesystem with QEMU direct kernel boot. The kernel is loaded from the guests directory structure that is exported from the host.
+
+The problem is that QEMU does not reload the kernel image file from disk during a guest reboot. This means it is not possible to update the kernel from inside the guest and do a simple reboot to load it. A full power cycle of the guest is required to load the updated kernel image.
+Steps to reproduce:
+1. Migrate a Linux guest to virtiofs as root fs. 
+2. Enable QEMU direct kernel boot and point to guest's kernel in the exported root filesystem. 
+3. Boot. 
+4. Update the kernel inside the guest. Overwrite the existing kernel image
+5. Issue `reboot` inside the guest. 
+6. When the guest reboots, the old kernel is still booted, even though the image file was overwritten. 
+7. Issue `poweroff` inside the guest. 
+8. Issue `virsh start <guest-vm>`
+9. Now the new kernel image is booted.
+Additional information:
+XML:
+```
+<type arch='x86_64' machine='pc-q35-7.0'>hvm</type>
+    <kernel>/media/vm/libvirt/images/alpine-q/root/boot/vmlinuz-virt</kernel>
+    <initrd>/media/vm/libvirt/images/alpine-q/root/boot/initramfs-virt</initrd>
+    <cmdline>rootfstype=virtiofs root=root rw</cmdline>
+    <boot dev='hd'/>
+    <bootmenu enable='no'/>
+  </os>
+
+...
+
+    <filesystem type='mount' accessmode='passthrough'>
+      <driver type='virtiofs'/>
+      <binary path='/usr/libexec/virtiofsd' xattr='on'>
+        <cache mode='always'/>
+        <lock posix='on' flock='on'/>
+      </binary>
+      <source dir='/media/vm/libvirt/images/alpine-q/root'/>
+      <target dir='root'/>
+      <address type='pci' domain='0x0000' bus='0x09' slot='0x00' function='0x0'/>
+    </filesystem>
+```
diff --git a/results/classifier/gemma3:12b/boot/1533848 b/results/classifier/gemma3:12b/boot/1533848
new file mode 100644
index 000000000..c21df5060
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1533848
@@ -0,0 +1,4 @@
+
+A workaround for Windows 7 ACPI SLIC table behavior when used with OVMF
+
+When OVMF is used, Windows 7 refuses to read SLIC ACPI table, passed via -acpitable option, because it expects oem id and oem table id to match in SLIC, XSDT, RSDT, FADT. There's a detailed discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=1248758
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1535497 b/results/classifier/gemma3:12b/boot/1535497
new file mode 100644
index 000000000..4f8bebaf1
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1535497
@@ -0,0 +1,21 @@
+
+Guest can not boot up when assigned more than 20 vcpus with option "-no-acpi"
+
+Environment:
+ -------------------------------
+ KVM commit/branch: da3f7ca3/next
+ Qemu commit/branch: 7b8a354d/master
+ Host OS: RHEL7.2 ia32e
+ Host Kernel: 4.4-rc2
+ Guest OS: RHEL7.2 ia32e
+
+Description:
+ --------------------------------
+When assign more than 20 vpcus with option "-no-acpi", guest can not boot up.
+
+Reproduce:
+ ----------------
+ 1.qemu-system-x86_64 --enable-kvm -m 1024 -smp 20 -no-acpi -device virtio-net-pci,netdev=nic0,mac=00:16:3e:17:9b:4c -netdev tap,id=nic0,script=/etc/kvm/qemu-ifup -drive file=/root/7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0
+
+
+Bisect show the bad commit is 9ee2e2625 of seabios.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1537 b/results/classifier/gemma3:12b/boot/1537
new file mode 100644
index 000000000..6e51f01f2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1537
@@ -0,0 +1,12 @@
+
+One-floppy windows 3.11  file manager does not work in tcg mode
+Description of problem:
+When I try to boot mini win 3.11 from https://archive.org/details/mwin-3 it boots into desktop ok, but double-clicking on file manager icon  result in black window/GPF (briefly flashing text I can't fully read).
+
+Starting it with boot choice 2 - with emm386 - same action result in machine reboot.
+
+Using same disk with kvm works for choice #2 (boot with emm386)
+Steps to reproduce:
+1. Download IMG file from Arhivce org
+2. Run it like I shown above
+3. Any (out of two) boot choices lead to same outcome - desktop and say ms-dos console works, but launching file manager gives you black screen/error
diff --git a/results/classifier/gemma3:12b/boot/1539940 b/results/classifier/gemma3:12b/boot/1539940
new file mode 100644
index 000000000..38d5d89da
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1539940
@@ -0,0 +1,30 @@
+
+Qemu 2.5 Solaris 8 and 9 sparc hang after terminal type menu
+
+Qemu command:
+qemu-system-sparc -nographic -monitor null -serial mon:telnet:localhost:3000,server -bios ../../Downloads/ss20_v2.25_rom -M SS-20 -hda ./solsparc -m 512 -cdrom ./sol-9-905hw-ga-sparc-dvd.iso -boot d -cpu "TI SuperSparc 60" -net nic,vlan=1,macaddr=52:54:0:12:34:56
+
+
+when i do disk2:d, the system loads until the terminal type menu.
+
+What type of terminal are you using?
+1) ANSI Standard CRT
+2) DEC VT52
+3) DEC VT100
+4) Heathkit 19
+5) Lear Siegler ADM31
+6) PC Console
+7) Sun Command Tool
+8) Sun Workstation
+9) Televideo 910
+10) Televideo 925
+11) Wyse Model 50
+12) X Terminal Emulator (xterms)
+13) CDE Terminal Emulator (dtterm)
+14) Other
+Type the number of your choice and press Return: 3
+syslog service starting.
+savecore: no dump device configured
+Running in command line mode
+
+And nothing happens after that. Anyone encountered this issue?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1563887 b/results/classifier/gemma3:12b/boot/1563887
new file mode 100644
index 000000000..337e0af0a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1563887
@@ -0,0 +1,103 @@
+
+qemu-system-ppc64 freezes on starting image on ppc64le
+
+qemu-system-ppc64 running on Ubuntu 16.04 beta-2 fails to start an image as part of the certification process. This on an IBM ppc64le in PowerVM mode running Ubuntu 16.04 beta-2 deployed by MAAS 1.9.1.
+
+qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=
+xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio
+qemu-system-ppc64: -drive file=seed.iso,if=virtio: Could not open 'seed.iso': No such file or directory
+ubuntu@alpine01:~$ cd kvm
+ubuntu@alpine01:~/kvm$ qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive f
+ile=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio
+WARNING: Image format was not specified for 'seed.iso' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+
+
+SLOF **********************************************************************
+QEMU Starting
+ Build Date = Jan 29 2016 18:58:37
+ FW Version = buildd@ release 20151103
+ Press "s" to enter Open Firmware.
+
+Populating /vdevice methods
+Populating /vdevice/vty@71000000
+Populating /vdevice/nvram@71000001
+Populating /vdevice/l-lan@71000002
+Populating /vdevice/v-scsi@71000003
+       SCSI: Looking for devices
+          8200000000000000 CD-ROM   : "QEMU     QEMU CD-ROM      2.5+"
+Populating /pci@800000020000000
+                     00 1800 (D) : 1af4 1001    virtio [ block ]
+                     00 1000 (D) : 1af4 1001    virtio [ block ]
+                     00 0800 (D) : 106b 003f    serial bus [ usb-ohci ]
+                     00 0000 (D) : 1234 1111    qemu vga
+No NVRAM common partition, re-initializing...
+Installing QEMU fb
+
+
+
+Scanning USB
+  OHCI: initializing
+    USB Keyboard
+    USB mouse   
+No console specified using screen & keyboard
+
+  Welcome to Open Firmware
+
+  Copyright (c) 2004, 2011 IBM Corporation All rights reserved.
+  This program and the accompanying materials are made available
+  under the terms of the BSD License available at
+  http://www.opensource.org/licenses/bsd-license.php
+
+
+Trying to load:  from: /pci@800000020000000/scsi@3 ...
+E3404: Not a bootable device!
+Trying to load:  from: /pci@800000020000000/scsi@2 ...   Successfully loaded
+Linux ppc64le   
+#31-Ubuntu SMP F
+
+ProblemType: Bug
+DistroRelease: Ubuntu 16.04
+Package: qemu-system-ppc 1:2.5+dfsg-5ubuntu6
+ProcVersionSignature: Ubuntu 4.4.0-16.32-generic 4.4.6
+Uname: Linux 4.4.0-16-generic ppc64le
+ApportVersion: 2.20-0ubuntu3
+Architecture: ppc64el
+Date: Wed Mar 30 14:10:01 2016
+KvmCmdLine:
+ COMMAND         STAT  EUID  RUID   PID  PPID %CPU COMMAND
+ kvm-irqfd-clean S<       0     0  1172     2  0.0 [kvm-irqfd-clean]
+ qemu-nbd        Ssl      0     0 13467     1  0.0 qemu-nbd -c /dev/nbd0 xenial-server-cloudimg-ppc64el-disk1.img
+ qemu-system-ppc Sl+   1000  1000 18973 18896  101 qemu-system-ppc64 -m 256 -display none -nographic -net nic -net user,net=10.0.0.0/8,host=10.0.0.1,hostfwd=tcp::2222-:22 -machine pseries -drive file=xenial-server-cloudimg-ppc64el-disk1.img,if=virtio -drive file=seed.iso,if=virtio
+Lsusb: Error: command ['lsusb'] failed with exit code 1:
+ProcEnviron:
+ TERM=xterm
+ PATH=(custom, no user)
+ LANG=en_US.UTF-8
+ SHELL=/bin/bash
+ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinux-4.4.0-16-generic root=UUID=92d820c8-ab25-497b-9b1e-f1435992bbf3 ro
+ProcLoadAvg: 1.08 0.94 0.58 2/616 19571
+ProcLocks:
+ 1: POSIX  ADVISORY  WRITE 886 00:13:381 0 EOF
+ 2: POSIX  ADVISORY  WRITE 1339 00:13:528 0 EOF
+ 3: FLOCK  ADVISORY  WRITE 1284 00:13:522 0 EOF
+ 4: POSIX  ADVISORY  WRITE 2281 00:13:563 0 EOF
+ 5: POSIX  ADVISORY  WRITE 1331 00:13:536 0 EOF
+ProcSwaps:
+ Filename				Type		Size	Used	Priority
+ /swap.img                               file		8388544	0	-1
+ProcVersion: Linux version 4.4.0-16-generic (buildd@bos01-ppc64el-001) (gcc version 5.3.1 20160320 (Ubuntu/Linaro/IBM 5.3.1-12ubuntu4) ) #32-Ubuntu SMP Thu Mar 24 22:31:14 UTC 2016
+SourcePackage: qemu
+UpgradeStatus: No upgrade log present (probably fresh install)
+bootlist:
+ /pci@800000020000011/pci1014,034A@0/sas/disk@4068402c40
+ /pci@800000020000018/ethernet@0:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512
+ /pci@800000020000018/ethernet@0,1:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512
+ /pci@800000020000018/ethernet@0,2:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512
+ /pci@800000020000018/ethernet@0,3:speed=auto,duplex=auto,csarch,000.000.000.000,,000.000.000.000,000.000.000.000,5,5,000.000.000.000,512
+cpu_cores: Number of cores present = 8
+cpu_coreson: Number of cores online = 8
+cpu_smt: SMT=8
+lscfg_vp: Error: [Errno 2] No such file or directory: 'lscfg'
+lsmcode: Error: [Errno 2] No such file or directory: 'lsmcode'
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1572329 b/results/classifier/gemma3:12b/boot/1572329
new file mode 100644
index 000000000..25c6deadd
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1572329
@@ -0,0 +1,6 @@
+
+ARM bootloader does not set r0 to 0
+
+# arm-softmmu/qemu-system-arm -M raspi2 -m 1024 -smp 4 -kernel kernel.bin -serial stdio -dtb rpi2.dtb
+
+My code shows r0 = 0x31 while it should be 0.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1579327 b/results/classifier/gemma3:12b/boot/1579327
new file mode 100644
index 000000000..f44879983
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1579327
@@ -0,0 +1,120 @@
+
+emulation of vexpress-a9 vexpress-a15 in multicore mode seems to be broken
+
+Report based on:
+https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under
+
+I don't see any bug reports about vexpress boards emulation here, so I decided to let you know:
+
+version tested: qemu 2.0.0 on 32 bit Debian GNU/Linux
+
+There are issues with running u-boot on qemu vexpress-a9 ( it was reported to work ok at physical multicore board )  and vexpress-a15 with parameters -smp cores=2 r 3 or 4.
+So far those are two tested. I dont know ATM if any other board emulation works in multiprocessor mode
+
+Original post at stackoverflow:
+---------------------------------------------------------------------------------------------------
+I have tried numerous releases of u-boot since vexpress-a9 was introduced in u-bot stable release. Under qemu with multicore emulation its behaving unstable - mostly crashes instantly after loading. Sometimes it loads without issues but its rare. My version of qemu is 2.0.0 on x86 32bit Debian. I would be interested to hear if you succeeded in runing it under qemu with multicore emulation ( if yes which version of qemu and u-boot ) or physical versatile express board with multiple cores.
+
+Example outputs are
+
+$ qemu-system-arm -M vexpress-a9 -nographic -kernel u-boot -smp cores=2
+U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19)
+
+DRAM:  128 MiB
+WARNING: Caches not enabled
+undefined instruction
+pc : [<00000000>]      lr : [<00000000>]
+sp : 60000ef0  ip : 67eedfd8     fp : 00000000
+r10: 00000000  r9 : 00000000     r8 : 60000f00
+r7 : 00000000  r6 : 608146ac     r5 : 60828365  r4 : 0000004d
+r3 : 00000000  r2 : 00000000     r1 : 60000f80  r0 : 47cc9e10
+Flags: nzcv  IRQs on  FIQs on  Mode USER_26
+Resetting CPU ...
+resetting ...
+Flash: 256 MiB
+MMC:   MMC: 0
+*** Warning - bad CRC, using default environment
+
+In:    serial
+Out:   serial
+Err:   serial
+Net:   smc911x-0
+Warning: smc911x-0 using MAC address from net device
+
+Hit any key to stop autoboot:  0 
+Wrong Image Format for bootm command
+ERROR: can't get kernel image!
+VExpress# 
+
+This time it was loaded
+
+Other time it was not...
+
+$ qemu-system-arm -M vexpress-a9 -nographic -kernel u-boot -smp cores=2
+
+
+U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19)
+
+DRAM:  128 MiB
+WARNING: Caches not enabled
+
+
+U-Boot 2013.01.01-dirty (May 05 2016 - 08:27:19)
+
+DRAM:  128 MiB
+WARNING: Caches not enabled
+Flash: 256 MiB
+MMC:   MMC: 0
+*** Warning - bad CRC, using default environment
+
+In:    serial
+Out:   serial
+Err:   serial
+Net:   smc911x-0
+Warning: smc911x-0 using MAC address from net device
+
+Hit any key to stop autoboot:  2 qemu: fatal: Trying to execute code outside RAM or ROM at 0x6f71c004
+
+R00=00418937 R01=000003e8 R02=00418937 R03=00000000
+R04=00000000 R05=67eedf58 R06=67f8e000 R07=00000002
+R08=00418937 R09=0778e000 R10=6082f688 R11=00000000
+R12=67eedfd8 R13=00000000 R14=67fb82c0 R15=6f71c004
+PSR=200001db --C- A und32
+s00=00000000 s01=00000000 d00=0000000000000000
+s02=00000000 s03=00000000 d01=0000000000000000
+s04=00000000 s05=00000000 d02=0000000000000000
+s06=00000000 s07=00000000 d03=0000000000000000
+s08=00000000 s09=00000000 d04=0000000000000000
+s10=00000000 s11=00000000 d05=0000000000000000
+vs12=00000000 s13=00000000 d06=0000000000000000
+s14=00000000 s15=00000000 d07=0000000000000000
+s16=00000000 s17=00000000 d08=0000000000000000
+s18=00000000 s19=00000000 d09=0000000000000000
+s20=00000000 s21=00000000 d10=0000000000000000
+s22=00000000 s23=00000000 d11=0000000000000000
+s24=00000000 s25=00000000 d12=0000000000000000
+s26=00000000 s27=00000000 d13=0000000000000000
+s28=00000000 s29=00000000 d14=0000000000000000
+s30=00000000 s31=00000000 d15=0000000000000000
+s32=00000000 s33=00000000 d16=0000000000000000
+s34=00000000 s35=00000000 d17=0000000000000000
+s36=00000000 s37=00000000 d18=0000000000000000
+s38=00000000 s39=00000000 d19=0000000000000000
+s40=00000000 s41=00000000 d20=0000000000000000
+s42=00000000 s43=00000000 d21=0000000000000000
+s44=00000000 s45=00000000 d22=0000000000000000
+s46=00000000 s47=00000000 d23=0000000000000000
+s48=00000000 s49=00000000 d24=0000000000000000
+s50=00000000 s51=00000000 d25=0000000000000000
+s52=00000000 s53=00000000 d26=0000000000000000
+s54=00000000 s55=00000000 d27=0000000000000000
+s56=00000000 s57=00000000 d28=0000000000000000
+s58=00000000 s59=00000000 d29=0000000000000000
+s60=00000000 s61=00000000 d30=0000000000000000
+s62=00000000 s63=00000000 d31=0000000000000000
+FPSCR: 00000000
+-------------------------------------------------------------------------------------------------
+end of post
+
+Original discussion at ( includes comments of head custodian of Das U-boot about u-boot working on physical board versatile express a9 and him having issues with runing Linux distro at qemu vexpress-a9 board emulation ):
+https://stackoverflow.com/questions/37068688/have-you-got-issues-with-running-u-boot-for-versatile-express-a9-platform-under
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1586229 b/results/classifier/gemma3:12b/boot/1586229
new file mode 100644
index 000000000..42bfb0dc2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1586229
@@ -0,0 +1,28 @@
+
+seabios hell
+
+getting weird annoying seabios hell and not sure how to fix it.
+
+ok.
+
+there IS a SEA-BIOS. There IS a way in.
+
+-I found it by mistake.(and yall need to move the BIOS key...its in the wrong place)
+
+I was tryng to boot Yosemite to re-install. I mashed the key too early and it wanted to boot the hard drive.
+
+Apparently the bios loads AFTER the hard drive wants to boot, not BEFORE it.And it will ONLY load when booting a hard disk.
+
+..Booting hard disk...[mash F8 here but let go and wait]
+eventually will want to load the OS and clear the screen[mash F8 again]
+
+--Youre in!
+
+Its tiny, like a mini award bios but youre in! 
+-Change anything HERE, though...and kiss booting a cd goodbye!
+
+Im trying to diagnose a black screen, seems related to seabios, not the vga driver.
+
+-mayhaps wants to boot hard disk but in fact its not bootable as the installer hung(and often unices install bootloader late in process)?
+
+I cant boot the disc to reinstall to tell. But I have a few dos iso lying around...hmmm.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1587211 b/results/classifier/gemma3:12b/boot/1587211
new file mode 100644
index 000000000..c7cf9440f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1587211
@@ -0,0 +1,93 @@
+
+qemu-system-i386/x86_64 crash with 1 MB guest RAM
+
+When launching qemu-system-i386 or qemu-system-x86_64 with 1 MB of RAM allocated to the guest (-m 1) and no guest image specified, QEMU will crash while trying to "execute code outside of RAM or ROM" after approximately 10 minutes. I discovered this while using QEMU 2.5.0, but I verified that it also occurs with 2.5.1.1 and the latest source available in git (2.6.50, commit d6550e9ed2e1a60d889dfb721de00d9a4e3bafbe). I built all of these different versions of QEMU on the same 64-bit Ubuntu 14.04.3 host using the distro's default GCC 4.8.4.
+
+Two observations:
+
+1. This only occurs when allocating 1 MB of RAM to the guest. When I allocate 2 MB, this does not happen. I tried running both i386/x86_64 QEMUs for hours with 2 MB and didn't observe this crash.
+
+2. This may be a SeaBIOS bug, as there is no guest code to execute. After enabling the SeaBIOS debug at the ISA 0x402 port and redirecting it to stdio, the last SeaBIOS state transition reported ("Booting from ROM... Booting from c980:0361") occurs immediately at QEMU startup with no further logging messages seen prior to the crash ten minutes later. My captured SeaBIOS debug output is here: http://pastebin.com/GXm2L44E
+
+To reproduce, use the following command lines:
+
+./i386-softmmu/qemu-system-i386 -display none -m 1 -monitor stdio
+./x86_64-softmmu/qemu-system-x86_64 -display none -m 1 -monitor stdio
+
+For both 32/64-bit QEMUs, the output is the same. After running for about 10 minutes (I've seen it take between 7m 15s (v2.5.1.1) to 10m 25s (v2.6.50) of runtime to occur by using the "time" command), the following output is shown:
+
+--- OUTPUT BEGINS ---
+e1000: Reading register at offset: 0x00002410. It is not fully implemented.
+e1000: Reading register at offset: 0x00002410. It is not fully implemented.
+e1000: Reading register at offset: 0x00002410. It is not fully implemented.
+e1000: Reading register at offset: 0x00002410. It is not fully implemented.
+e1000: Reading register at offset: 0x00002418. It is not fully implemented.
+e1000: Reading register at offset: 0x00002418. It is not fully implemented.
+e1000: Reading register at offset: 0x00002418. It is not fully implemented.
+e1000: Reading register at offset: 0x00002418. It is not fully implemented.
+e1000: Reading register at offset: 0x00002420. It is not fully implemented.
+e1000: Reading register at offset: 0x00002420. It is not fully implemented.
+e1000: Reading register at offset: 0x00002420. It is not fully implemented.
+e1000: Reading register at offset: 0x00002420. It is not fully implemented.
+e1000: Reading register at offset: 0x00002428. It is not fully implemented.
+e1000: Reading register at offset: 0x00002428. It is not fully implemented.
+e1000: Reading register at offset: 0x00002428. It is not fully implemented.
+e1000: Reading register at offset: 0x00002428. It is not fully implemented.
+e1000: Reading register at offset: 0x00002430. It is not fully implemented.
+e1000: Reading register at offset: 0x00002430. It is not fully implemented.
+e1000: Reading register at offset: 0x00002430. It is not fully implemented.
+e1000: Reading register at offset: 0x00002430. It is not fully implemented.
+e1000: Reading register at offset: 0x00003410. It is not fully implemented.
+e1000: Reading register at offset: 0x00003410. It is not fully implemented.
+e1000: Reading register at offset: 0x00003410. It is not fully implemented.
+e1000: Reading register at offset: 0x00003410. It is not fully implemented.
+e1000: Reading register at offset: 0x00003418. It is not fully implemented.
+e1000: Reading register at offset: 0x00003418. It is not fully implemented.
+e1000: Reading register at offset: 0x00003418. It is not fully implemented.
+e1000: Reading register at offset: 0x00003418. It is not fully implemented.
+e1000: Reading register at offset: 0x00003420. It is not fully implemented.
+e1000: Reading register at offset: 0x00003420. It is not fully implemented.
+e1000: Reading register at offset: 0x00003420. It is not fully implemented.
+e1000: Reading register at offset: 0x00003420. It is not fully implemented.
+e1000: Reading register at offset: 0x00003428. It is not fully implemented.
+e1000: Reading register at offset: 0x00003428. It is not fully implemented.
+e1000: Reading register at offset: 0x00003428. It is not fully implemented.
+e1000: Reading register at offset: 0x00003428. It is not fully implemented.
+e1000: Reading register at offset: 0x00003430. It is not fully implemented.
+e1000: Reading register at offset: 0x00003430. It is not fully implemented.
+e1000: Reading register at offset: 0x00003430. It is not fully implemented.
+e1000: Reading register at offset: 0x00003430. It is not fully implemented.
+e1000: Reading register at offset: 0x00010000. It is not fully implemented.
+e1000: Reading register at offset: 0x00010000. It is not fully implemented.
+e1000: Reading register at offset: 0x00010000. It is not fully implemented.
+e1000: Reading register at offset: 0x00010000. It is not fully implemented.
+qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a0063
+
+EAX=00100000 EBX=00000018 ECX=00002c06 EDX=0009cde0
+ESI=000caa20 EDI=00100000 EBP=ffffffff ESP=00007bcc
+EIP=000038e3 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 ffffffff 00cf9300
+CS =9c78 0009c780 ffffffff 008f9b00
+SS =0000 00000000 ffffffff 008f9300
+DS =9cf3 0009cf30 ffffffff 00cf9300
+FS =0000 00000000 ffffffff 00cf9300
+GS =0000 00000000 ffffffff 00cf9300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 00000000
+IDT=     00000000 000003ff
+CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
+DR6=ffff0ff0 DR7=00000400
+CCS=000000c2 CCD=00002c06 CCO=CLR     
+EFER=0000000000000000
+FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
+FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
+FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
+FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
+FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
+XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
+XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
+XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
+XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
+--- OUTPUT ENDS ---
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1588328 b/results/classifier/gemma3:12b/boot/1588328
new file mode 100644
index 000000000..777902b39
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1588328
@@ -0,0 +1,72 @@
+
+Qemu 2.6 Solaris 9 Sparc Segmentation Fault
+
+Hi,
+I tried the following command to boot Solaris 9 sparc:
+qemu-system-sparc -nographic -boot d -hda ./Spark9.disk -m 256 -cdrom sol-9-905hw-ga-sparc-dvd.iso -serial telnet:0.0.0.0:3000,server 
+
+It seems there are a few Segmentation Faults, one from the starting of the boot. Another at the beginning of the commandline installation.
+
+Trying 127.0.0.1...
+Connected to localhost.
+Escape character is '^]'.
+Configuration device id QEMU version 1 machine id 32
+Probing SBus slot 0 offset 0
+Probing SBus slot 1 offset 0
+Probing SBus slot 2 offset 0
+Probing SBus slot 3 offset 0
+Probing SBus slot 4 offset 0
+Probing SBus slot 5 offset 0
+Invalid FCode start byte
+CPUs: 1 x FMI,MB86904
+UUID: 00000000-0000-0000-0000-000000000000
+Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:19
+  Type 'help' for detailed information
+Trying cdrom:d...
+Not a bootable ELF image
+Loading a.out image...
+Loaded 7680 bytes
+entry point is 0x4000
+bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d
+
+Jumping to entry point 00004000 for type 00000005...
+switching to new context:
+SunOS Release 5.9 Version Generic_118558-34 32-bit
+Copyright 1983-2003 Sun Microsystems, Inc.  All rights reserved.
+Use is subject to license terms.
+WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0):
+	Corrupt label; wrong magic number
+
+Segmentation Fault
+Configuring /dev and /devices
+NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88)
+audio may not work correctly until it is stopped and restarted
+Segmentation Fault
+Using RPC Bootparams for network configuration information.
+Skipping interface le0
+Searching for configuration file(s)...
+Search complete.
+
+....
+
+What type of terminal are you using?
+ 1) ANSI Standard CRT
+ 2) DEC VT52
+ 3) DEC VT100
+ 4) Heathkit 19
+ 5) Lear Siegler ADM31
+ 6) PC Console
+ 7) Sun Command Tool
+ 8) Sun Workstation
+ 9) Televideo 910
+ 10) Televideo 925
+ 11) Wyse Model 50
+ 12) X Terminal Emulator (xterms)
+ 13) CDE Terminal Emulator (dtterm)
+ 14) Other
+Type the number of your choice and press Return: 3
+syslog service starting.
+savecore: no dump device configured
+Running in command line mode
+/sbin/disk0_install[109]: 143 Segmentation Fault
+/sbin/run_install[130]: 155 Segmentation Fault
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1589257 b/results/classifier/gemma3:12b/boot/1589257
new file mode 100644
index 000000000..dc536a4e6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1589257
@@ -0,0 +1,17 @@
+
+Boot with OVMF extremely slow to bootloader
+
+I have used Arch Linux in the past with the same version (2.5.0), the exact same OVMF code and vars, and the exact same VM settings with no issues. Now with Ubuntu, I am having the issue where boot up until Windows takes about 10x longer. Every CPU thread/core allocated gets used 100% while this is happening. After that, everything operates as normal. There is no abnormal logs produced by qemu, or I don't know how to debug.
+
+Here are my settings:
+
+Host:
+Ubuntu 16.04
+Qemu 2.5.0
+Relevant configs attached
+
+Guest:
+Windows 10
+VirtIO raw disk image
+VirtIO network
+Typical VGA passthrough setup, everything operating normally
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1590796 b/results/classifier/gemma3:12b/boot/1590796
new file mode 100644
index 000000000..2ff87d715
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1590796
@@ -0,0 +1,47 @@
+
+2.6.0 Windows 7 install hangs on splash screen, works ok with 2.5.1
+
+Hi maintainers,
+
+I have tried to install Windows 7 SP1 from the ISO. The install process hangs on the windows 4 color logo with qemu 2.6.0, it works and installs fine with 2.5.1.
+
+This is the script I used with 2.5.1 and it works perfectly fine:
+
+#!/bin/sh
+exec qemu-system-x86_64 \
+        -enable-kvm \
+        -uuid 0ec801a0-d215-464b-a658-8f43a24cb62e \
+        -machine q35 \
+        -cpu host \
+        -smp cores=2,threads=2 \
+        -drive file=disk/ovmfcode.flash,format=raw,readonly,if=pflash \
+        -drive file=disk/ovmfvars.flash,format=raw,if=pflash \
+        -drive file=disk/windows7.img,discard=unmap,detect-zeroes=unmap,cache=unsafe,if=virtio \
+        -drive file=ISO/windows7.iso,media=cdrom \
+        -drive file=ISO/virtiowin.iso,media=cdrom \
+        -netdev tap,id=nic-0,ifname=tap0,vhost=on,script=no,downscript=no \
+        -net nic,macaddr=52:54:00:01:00:01,netdev=nic-0,model=virtio \
+        -m 4G \
+        -vga qxl \
+        -soundhw ac97 \
+        -usbdevice tablet \
+        -rtc clock=host,base=utc \
+        -name "Windows 7" \
+        -monitor telnet:127.0.0.1:2001,server,nowait \
+        -daemonize
+
+The same hangs on the splash screen with 2.6.0
+
+Even the following simple script behaves the same and hangs at splash screen with 2.6.0:
+
+#!/bin/sh
+exec qemu-system-x86_64 \
+        -drive file=disk/windows7.img,if=ide \
+        -drive file=ISO/windows7.iso,media=cdrom \
+        -name "Windows 7" \
+        $@
+
+The ISO is Windows 7 Ultimate english version, Service Pack 1. 
+I reproduced the same behaviour on Gentoo and Arch, with the Qemu versions provided on both distributions.
+
+Cheers
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1591724 b/results/classifier/gemma3:12b/boot/1591724
new file mode 100644
index 000000000..9b83bc8f2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1591724
@@ -0,0 +1,21 @@
+
+Windows 7 installation DVD can't boot in qemu 2.6.0/OVMF
+
+With Qemu 2.5.50 (compiled from git some time ago) I can boot Windows 7 x64 installation DVD as follows:
+~/code/qemu-v2/bin/slic-v2/native/x86_64-softmmu/qemu-system-x86_64 \
+    -machine type=pc,accel=kvm \
+    -enable-kvm \
+    -cpu host \
+    -m 2048 \
+    -vga cirrus \
+    -boot d \
+    -drive if=pflash,file=/vms/ovmf_x64_firstrun.bin,format=raw \
+    -cdrom /vms/win7_sp1.iso \
+    -monitor stdio
+
+This bug suggests different vga options https://bugs.launchpad.net/qemu/+bug/1581936. Here's the behaviours I'm getting with 2.6.0:
+
+std - "Starting Windows" with wavering flag hangs indefinitely
+cirrus - at "Starting Windows" wasps of light freeze before assembling into a flag
+qxl - "Starting Windows" with wavering flag hangs indefinitely
+virtio - "Starting Windows" with wavering flag hangs indefinitely
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1596832 b/results/classifier/gemma3:12b/boot/1596832
new file mode 100644
index 000000000..e2d4858f4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1596832
@@ -0,0 +1,56 @@
+
+e500 -bios/-kernel broken with big images
+
+This is tested using qemu 2.4.1, but it looks like the code qemu/hw/ppc/e500.c has not changed since. This looks like the source of the problem:  http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3812c71ffaa2cf733c3087792b859fef30b7545f
+
+
+What works:
+----------
+
+Basic invocation qemu-system-ppc -machine ppce500  -monitor stdio  -bios u-boot.e500 works, I get the uboot prompt and this:
+
+(qemu) info roms
+addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500"
+addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500"
+
+
+Passing u-boot.e500 image as kernel (-bios u-boot.e500 -kernel u-boot.e500) appears to work, $qemu_kernel_addr is filled in, though (as expected) uboot complains about the image format.
+
+(qemu) info roms
+addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500"
+addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500"
+addr=0000000002000000 size=0x054e8c mem=ram name=".../qemu/share/qemu/u-boot.e500
+
+
+
+What doesn't work:
+-----------------
+
+However, once I try to load a big image (>=32 MiB), uboot doesn't even show anything:
+
+qemu-system-ppc -machine ppce500  -monitor stdio -bios u-boot.e500 -kernel boot/vmlinux -m 1024
+
+(qemu) info roms
+addr=0000000000f00000 size=0x044b8c mem=ram name="phdr #0: .../qemu/share/qemu/u-boot.e500"
+addr=0000000000f81000 size=0x006b00 mem=ram name="phdr #1: .../qemu/share/qemu/u-boot.e500"
+addr=0000000002000000 size=0x27aeedc mem=ram name="boot/vmlinux"
+
+...
+(gdb) bt
+#0  0x00f2efcc in ?? ()
+#1  0x00f31554 in ?? ()
+#2  0x00f03f4c in ?? ()
+#3  0x00f04458 in ?? ()
+#4  0x00f028dc in ?? ()
+#5  0x00f01080 in ?? ()
+
+
+
+The thing is, this used to work +- before the commit, where I'd just pass the image as -kernel option, and it booted.
+
+
+If I do that now (w/o the -bios option, using the exact same image), the kernel gets loaded twice, only at different addresses (the cause is obvious from the commit), causing overlap error:
+
+qemu-system-ppc -machine ppce500  -monitor stdio  -kernel boot/vmlinux -m 1024
+QEMU 2.4.1 monitor - type 'help' for more information
+(qemu) rom: requested regions overlap (rom boot/vmlinux. free=0x00000000027492fc, addr=0x0000000002000000)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1599214 b/results/classifier/gemma3:12b/boot/1599214
new file mode 100644
index 000000000..b0dcc9d0f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1599214
@@ -0,0 +1,23 @@
+
+virtlogd: qemu 2.6.0 doesn't log boot message
+
+This report is related to the OpenStack Nova bug [1].
+
+OpenStack tries to utilize the "virtlogd" feature of qemu [2].
+
+steps to reproduce:
+1) launch a quest with qemu 2.6.0 which uses virtlogd for the stdout/stderr of its char device
+2) check the contents of the backing file of that char device
+
+expected result:
+The boot messages of the guest are logged in this file
+
+actual result:
+The file is empty
+
+notes:
+When I'm connected to that char device and reboot the guest, I see the boot messages in the terminal and also in the backing log file.
+
+References:
+[1] https://bugs.launchpad.net/nova/+bug/1597789
+[2] http://git.qemu.org/?p=qemu.git;a=blobdiff;f=qemu-char.c;h=11caa5648de99c9e0ee158f280fbc02ab05915d3;hp=d7be1851e5e9d268aa924a05958da292b048839c;hb=d0d7708ba29cbcc343364a46bff981e0ff88366f;hpb=f1c17521e79df863a5771d96974fab0d07f02be0
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1629282 b/results/classifier/gemma3:12b/boot/1629282
new file mode 100644
index 000000000..eba3c337e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1629282
@@ -0,0 +1,22 @@
+
+QEMU (still) hangs on Windows 7 install
+
+I'm trying to install Windows 7 as guest, but the machine still hangs (more precisely, the windows icon keeps flashing, but never goes past this stage).
+
+I think this is a different bug from https://bugs.launchpad.net/qemu/+bug/1581936.
+
+Specifically, its happens when the OVMF BIOS is used, and I can't find any workaround (in the above bug, by changing the display, the installation doesn't hang).
+
+The most minimal commandline that reproduces the issue is (generic format):
+
+$QEMU_BINARY \
+  -drive if=pflash,format=raw,readonly,file=$QEMU_BIOS \
+  -drive if=pflash,format=raw,file=$QEMU_BIOS_TMP \
+  -enable-kvm \
+  -m $QEMU_MEMORY \
+  -display std \
+  -cpu host,kvm=off -smp 4,sockets=1,cores=4 \
+  -cdrom $QEMU_WINDOWS_7_CD \
+;
+
+I'm using `OVMF_15214.fd` as BIOS.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1629483 b/results/classifier/gemma3:12b/boot/1629483
new file mode 100644
index 000000000..ea7a07e98
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1629483
@@ -0,0 +1,30 @@
+
+Build fails on optionrom
+
+Git pseudo-bisected (focused on optionrom commits) it to this commit.
+
+commit cdbd727c20ad7aac7797dc8c95e485e1a4c6901b
+Author: Richard Henderson <email address hidden>
+Date:   Thu Jul 7 21:49:36 2016 -0700
+
+    build: Use $(AS) for optionrom explicitly
+
+
+Build output (non-verbose):
+
+  AS    optionrom/linuxboot.o
+cpp: fatal error: '-c' is not a valid option to the preprocessor
+compilation terminated.
+cpp: fatal error: '-c' is not a valid option to the preprocessor
+compilation terminated.
+  CC    optionrom/linuxboot_dma.o
+  CC    /home/bkamath/dev/workspace/block-2/mothra/output/sp0/targetqga/main.o
+  AS    optionrom/kvmvapic.o
+cpp: fatal error: '-c' is not a valid option to the preprocessor
+compilation terminated.
+
+Steps to reproduce:
+Using buildroot and overriding qemu version to 2.7.0
+Fedora 24, cpp (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
+
+I tried first just building without the -c option but it hangs indefinitely. Reverting the above listed commit fixes the problem on my platform. I didn't dive much further into this, because this seems like a regression.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1633 b/results/classifier/gemma3:12b/boot/1633
new file mode 100644
index 000000000..4647f6513
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1633
@@ -0,0 +1,69 @@
+
+[8.0.0] Broken icount support on RISC-V
+Description of problem:
+After https://gitlab.com/qemu-project/qemu/-/commit/5a4ae64cac49564354cd6f17598840e4af70e4f5 was merged, RISC-V VMs no longer run with -icount 1 specified in the QEMU arguments. Reverting this commit resolves the issue.
+Steps to reproduce:
+1. Download preinstalled Ubuntu 22.04.2 image from [here](https://cdimage.ubuntu.com/releases/22.04.2/release/ubuntu-22.04.2-preinstalled-server-riscv64+unmatched.img.xz)
+2. Download uboot from [here](http://security.ubuntu.com/ubuntu/pool/main/u/u-boot/u-boot-qemu_2022.01+dfsg-2ubuntu2.3_all.deb)
+3. Extract both.
+4. Run with the command-line specified above.
+Additional information:
+Reading Ubuntu wiki describing how to run RISC-V VMs can help: https://wiki.ubuntu.com/RISC-V/QEMU
+
+Full output:
+
+```
+% qemu-system-riscv64 \                     
+-machine virt -nographic -m 2048 -smp 4 \
+-kernel u-boot/qemu-riscv64_smode/uboot.elf \
+-device virtio-net-device,netdev=eth0 -netdev user,id=eth0 \
+-drive file=ubuntu-22.04.2-preinstalled-server-riscv64+unmatched.img,format=raw,if=virtio -icount 1
+
+OpenSBI v1.2
+   ____                    _____ ____ _____
+  / __ \                  / ____|  _ \_   _|
+ | |  | |_ __   ___ _ __ | (___ | |_) || |
+ | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
+ | |__| | |_) |  __/ | | |____) | |_) || |_
+  \____/| .__/ \___|_| |_|_____/|____/_____|
+        | |
+        |_|
+
+Platform Name             : riscv-virtio,qemu
+Platform Features         : medeleg
+Platform HART Count       : 4
+Platform IPI Device       : aclint-mswi
+Platform Timer Device     : aclint-mtimer @ 10000000Hz
+Platform Console Device   : uart8250
+Platform HSM Device       : ---
+Platform PMU Device       : ---
+Platform Reboot Device    : sifive_test
+Platform Shutdown Device  : sifive_test
+Firmware Base             : 0x80000000
+Firmware Size             : 236 KB
+Runtime SBI Version       : 1.0
+
+Domain0 Name              : root
+Domain0 Boot HART         : 0
+Domain0 HARTs             : 0*,1*,2*,3*
+Domain0 Region00          : 0x0000000002000000-0x000000000200ffff (I)
+Domain0 Region01          : 0x0000000080000000-0x000000008003ffff ()
+Domain0 Region02          : 0x0000000000000000-0xffffffffffffffff (R,W,X)
+Domain0 Next Address      : 0x0000000080200000
+Domain0 Next Arg1         : 0x00000000bfe00000
+Domain0 Next Mode         : S-mode
+Domain0 SysReset          : yes
+
+Boot HART ID              : 0
+Boot HART Domain          : root
+Boot HART Priv Version    : v1.12
+Boot HART Base ISA        : rv64imafdch
+Boot HART ISA Extensions  : time,sstc
+Boot HART PMP Count       : 16
+Boot HART PMP Granularity : 4
+Boot HART PMP Address Bits: 54
+Boot HART MHPM Count      : 16
+Boot HART MIDELEG         : 0x0000000000001666
+Boot HART MEDELEG         : 0x0000000000f0b509
+qemu-system-riscv64: Bad icount read
+```
diff --git a/results/classifier/gemma3:12b/boot/1634 b/results/classifier/gemma3:12b/boot/1634
new file mode 100644
index 000000000..e68540398
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1634
@@ -0,0 +1,19 @@
+
+[8.0.0] Broken snapshot replay support on PowerPC
+Description of problem:
+QEMU 8.0.0 can no longer replay snapshots on PowerPC e500mc (Book-E) architecture. The issue is caused by https://gitlab.com/qemu-project/qemu/-/commit/c4b075318eb1e87de5fc942e6b987694a0e677e1, reverting this commit solves the issue.
+Steps to reproduce:
+1. Run bare metal example from the attachment with the first command-line to create snapshot.
+2. Run bare metal example from the attachment with the second command-line to replay snapshot.
+Additional information:
+Any e500mc example would do really. I was unable to find a prebuilt Linux distribution, thus just wrote a minimal sample that prints hello world to UART: [ppc-e500.zip](/uploads/f9328c4b8355a92877d784661aa69fa4/ppc-e500.zip)
+
+Log output:
+
+```
+% qemu-system-ppc -cpu e500mc -M ppce500 -m 128M -net none -icount 1,rr=record,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr -display none -kernel hello.elf -serial stdio
+Hello world
+qemu-system-ppc: terminating on signal 2 from pid 4505 (<unknown process>)
+% qemu-system-ppc -cpu e500mc -M ppce500 -m 128M -net none -icount 1,rr=replay,rrfile=main.bin,rrsnapshot=init -drive file=empty.qcow2,if=none,id=rr -display none -kernel hello.elf -serial stdio
+qemu-system-ppc: Missing random event in the replay log
+```
diff --git a/results/classifier/gemma3:12b/boot/1637693 b/results/classifier/gemma3:12b/boot/1637693
new file mode 100644
index 000000000..d26c09156
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1637693
@@ -0,0 +1,8 @@
+
+QEMU not able to create vm with pflash and UEFI bios
+
+Running Fedora 24 with the virt-preview repo on QEMU Version 2.7.0 and libvirt version 2.2.0. Tried to install a windows 10 vm with the OVMF bios and this error happens every time, it didnt happen when using the stable version of qemu for fedora 24.
+
+libvirtError: internal error: qemu unexpectedly closed the monitor: 2016-10-29T04:07:29.678518Z qemu-system-x86_64: -drive file=/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw,if=pflash,format=raw,unit=0,readonly=on: oversized backing file, pflash segments cannot be mapped under 00000000ff800000
+
+Any ideas?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1639394 b/results/classifier/gemma3:12b/boot/1639394
new file mode 100644
index 000000000..7546f3d17
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1639394
@@ -0,0 +1,24 @@
+
+Unable to boot Solaris 8/9 x86 under Fedora 24
+
+qemu-system-x86_64 -version
+QEMU emulator version 2.6.2 (qemu-2.6.2-4.fc24), Copyright (c) 2003-2008 Fabrice Bellard
+
+Try several ways without success, I think it was a regression because problem seems to be related with ide fixed on 0.6.0:
+- int13 CDROM BIOS fix (aka Solaris x86 install CD fix)
+- int15, ah=86 BIOS fix (aka Solaris x86 hardware probe hang up fix)
+
+Solaris 10/11 works without a problem, also booting with "scsi" will circumvent initial problem, but later found problems related with "scsi" cdrom boot and also will not found the "ide" disk device.
+
+
+qemu-system-i386 -m 712 -drive file=/dev/Virtual_hdd/beryllium0,format=raw -cdrom /repo/Isos/sol-9_905_x86.iso
+
+SunOS Secondary Boot version 3.00
+
+prom_panic: Could not mount filesystem.
+Entering boot debugger:
+[136419]
+
+
+Regards,
+\\CA,
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1649040 b/results/classifier/gemma3:12b/boot/1649040
new file mode 100644
index 000000000..857f851c4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1649040
@@ -0,0 +1,65 @@
+
+Ubuntu 16.04.1 Grub Splash Doesn't Appear
+
+My Specs:
+
+Slackware 14.2 x86_64 > Host
+QEMU 2.7.0 
+
+Ubuntu 16.04.1 > Guest
+
+Start options for Ubuntu:
+
+qemu-system-x86_64 -drive format=raw,file=ubuntu.img \
+-cpu host \
+--enable-kvm \
+-smp 2 \
+-m 4096 \
+-vga vmware \
+-soundhw ac97 \
+-usbdevice tablet \
+-rtc base=localtime \
+-usbdevice host:0781:5575
+
+
+
+I've started Ubuntu around 6-8 times, and I have only see the Grub Boot Splash appear twice, so pretty much without fail it typically boots past the grub splash and automatically boots...
+
+
+These are the /etc/default/grub settings; (I only changed these options GRUB_TIMEOUT=15 and GRUB_GFXMODE=1440x900)
+
+
+# If you change this file, run 'update-grub' afterwards to update
+# /boot/grub/grub.cfg.
+# For full documentation of the options in this file, see:
+#   info -f grub -n 'Simple configuration'
+
+GRUB_DEFAULT=0
+GRUB_HIDDEN_TIMEOUT=0
+GRUB_HIDDEN_TIMEOUT_QUIET=true
+GRUB_TIMEOUT=15
+GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
+GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
+GRUB_CMDLINE_LINUX=""
+
+# Uncomment to enable BadRAM filtering, modify to suit your needs
+# This works with Linux (no patch required) and with any kernel that obtains
+# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
+#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
+
+# Uncomment to disable graphical terminal (grub-pc only)
+#GRUB_TERMINAL=console
+
+# The resolution used on graphical terminal
+# note that you can use only modes which your graphic card supports via VBE
+# you can see them in real GRUB with the command `vbeinfo'
+GRUB_GFXMODE=1440x900
+
+# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
+#GRUB_DISABLE_LINUX_UUID=true
+
+# Uncomment to disable generation of recovery mode menu entries
+#GRUB_DISABLE_RECOVERY="true"
+
+# Uncomment to get a beep at grub start
+#GRUB_INIT_TUNE="480 440 1"
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1652333 b/results/classifier/gemma3:12b/boot/1652333
new file mode 100644
index 000000000..17ba9d073
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1652333
@@ -0,0 +1,10 @@
+
+TCG mode fails to boot Linux kernel with qemu 2.6.0 and libvirt 2.0.0
+
+Trying to boot a Cirros (minimal Linux) VM with qemu 2.6.0 and libvirt 2.0.0 in TCG mode fails for me. The VM gets stuck in "Starting up ..." and never moves on. The command line used to boot the VM was:
+
+LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=instance-00000002,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-00000002/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=tcg,usb=off -cpu SandyBridge,+osxsave,+hypervisor,+xsaveopt -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c -smbios 'type=1,manufacturer=Red Hat,product=OpenStack Compute,version=14.0.2-7.el7ost,serial=edd3a67d-6ce5-4c36-8f20-085d1097abb7,uuid=ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-00000002/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=28,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:27:73,bus=pci.0,addr=0x3 -add-fd set=1,fd=31 -chardev file,id=charserial0,path=/dev/fdset/1,append=on -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
+
+A qcow2 image can be downloaded from http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img to reproduce the issue. I've seen a similar failure with a CentOS 7.2 image.
+
+I am also attaching the libvirt log from the failed VM.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1653063 b/results/classifier/gemma3:12b/boot/1653063
new file mode 100644
index 000000000..d32909489
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1653063
@@ -0,0 +1,30 @@
+
+qemu-system-arm hangs with -icount and -nodefaults
+
+I tested with the latest git repo, (commit: dbe2b65566e76d3c3a0c3358285c0336ac61e757).
+
+My configure options when building QEMU:
+'../configure' '--prefix=$HOME/local/qemu.git' '--target-list=aarch64-softmmu,arm-softmmu' '--cpu=x86_64' '--cc=gcc' '--disable-user' '--disable-sdl' '--disable-stack-protector' '--disable-attr' '--disable-pie' '--disable-linux-aio' '--disable-tpm' '--without-system-pixman' '--disable-docs' '--disable-guest-agent' '--disable-guest-agent-msi' '--disable-modules' '--disable-sparse' '--disable-gnutls' '--disable-nettle' '--disable-gcrypt' '--disable-gtk' '--disable-vte' '--disable-curses' '--disable-vnc' '--disable-cocoa' '--disable-virtfs' '--disable-xen' '--disable-brlapi' '--disable-curl' '--disable-bluez' '--disable-rdma' '--disable-uuid' '--disable-vde' '--disable-netmap' '--disable-cap-ng' '--disable-attr' '--disable-vhost-net' '--disable-spice' '--disable-rbd' '--disable-libiscsi' '--disable-libnfs' '--disable-smartcard' '--disable-libusb' '--disable-usb-redir' '--disable-lzo' '--disable-snappy' '--disable-bzip2' '--disable-seccomp' '--disable-glusterfs' '--disable-archipelago' '--disable-libssh2' '--disable-vhdx' '--disable-numa' '--disable-werror' '--disable-blobs' '--disable-vhost-scsi' '--enable-debug' '--disable-strip' '--enable-debug-tcg' '--enable-debug-info' '--extra-cflags=-fPIC'
+
+My host OS is Redhat RHEL-6.5. uname command gives:
+Linux rslpc1 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
+
+The test image is downloaded from http://wiki.qemu.org/download/arm-test-0.2.tar.gz
+
+The command to re-produce the problem:
+qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0"
+
+After console prints the message below:
+"Uncompressing Linux.......................................................................... done, booting the kernel."
+there's no further action noticed.
+
+If "-icount" is not set, namely run as:
+qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -nodefaults -chardev stdio,mux=on,id=char0 -serial chardev:char0 --append "console=ttyAMA0"
+
+or if "-nodefaults" is not set, namely run as:
+qemu-system-arm -M integratorcp -kernel arm-test/zImage.integrator -initrd arm-test/arm_root.img -nographic -icount 1 --append "console=ttyAMA0"
+
+The Linux boot procedure can finish successfully.
+
+Thanks.
+Hansni
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1660 b/results/classifier/gemma3:12b/boot/1660
new file mode 100644
index 000000000..8a99cfb79
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1660
@@ -0,0 +1,2 @@
+
+tests/avocado/linux_ssh_mips_malta.py references mips image URLs that doesn't exist any more
diff --git a/results/classifier/gemma3:12b/boot/1660010 b/results/classifier/gemma3:12b/boot/1660010
new file mode 100644
index 000000000..f9baabd6c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1660010
@@ -0,0 +1,12 @@
+
+AArch64 system emulation cannot execute virt uefi in 2.7 or 2.8
+
+The UEFI firmware file is retrieved from http://snapshots.linaro.org/components/kernel/linaro-edk2/latest/release/qemu64/QEMU_EFI.fd .
+
+The error is:
+```
+TODO /var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg_qemu_tb_exec()
+/var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg fatal error
+```
+
+(both 2.7.0 and 2.8.0 are tested to fail, 2.6.1 works)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1670175 b/results/classifier/gemma3:12b/boot/1670175
new file mode 100644
index 000000000..9ae854b73
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1670175
@@ -0,0 +1,63 @@
+
+qemu-system-sparc64 with tribblix-sparc-0m16.iso ends with "panic - kernel: no nucleus hblk8 to allocate"
+
+> qemu-system-sparc64 -m 1024 -cdrom Downloads/tribblix-sparc-0m16.iso -boot d -nographic
+OpenBIOS for Sparc64
+Configuration device id QEMU version 1 machine id 0
+kernel cmdline 
+CPUs: 1 x SUNW,UltraSPARC-IIi
+UUID: 00000000-0000-0000-0000-000000000000
+Welcome to OpenBIOS v1.1 built on Nov 24 2016 21:23
+  Type 'help' for detailed information
+Trying cdrom:f...
+Not a bootable ELF image
+Not a bootable a.out image
+
+Loading FCode image...
+Loaded 7120 bytes
+entry point is 0x4000
+Evaluating FCode...
+Evaluating FCode...
+Ignoring failed claim for va 10a96a0 memsz 19!
+Ignoring failed claim for va 1000000 memsz d1fb6!
+Ignoring failed claim for va 1402000 memsz 32518!
+Ignoring failed claim for va 1800000 memsz 52ac8!
+SunOS Release 5.11 Version tribblix-m16 64-bit
+Copyright (c) 1983, 2010, Oracle and/or its affiliates. All rights reserved.
+could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught
+interpret \ ident	"%Z%%M%	%I%	%E% SMI"
+\ Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
+\ Use is subject to license terms.
+\
+\ CDDL HEADER START
+\
+\ The contents of this file are subject to the terms of the
+\ Common Development and Distribution License, Version 1.0 only
+\ (the "License").  You may not use this file except in compliance
+\ with the License.
+\
+\ You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+\ or http://www.opensolaris.org/os/licensing.
+\ See the License for 
+WARNING: add_spec: No major number for sf
+panic - kernel: no nucleus hblk8 to allocate
+EXIT
+
+QEMU keeps running (CPU is on 100 % all the time), I can interact with the prompt:
+
+0 > boot
+Not a Linux kernel image
+Not a bootable ELF image
+Not a bootable a.out image
+
+Loading FCode image...
+Unhandled Exception 0x0000000000000018
+PC = 0x00000000ffd25310 NPC = 0x00000000ffd25314
+Stopping execution
+
+> qemu-system-sparc64 -version
+QEMU emulator version 2.8.0(Virtualization:Staging / SLE_12_SP2)
+
+from https://build.opensuse.org/package/show/Virtualization:Staging/qemu on openSUSE Leap 42.2.
+
+ISO: http://pkgs.tribblix.org/iso/tribblix-sparc-0m16.iso.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1671173 b/results/classifier/gemma3:12b/boot/1671173
new file mode 100644
index 000000000..d04415e3e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1671173
@@ -0,0 +1,34 @@
+
+OS started to crash with a message: "Trying to execute code outside RAM or ROM"
+
+There is a project (https://github.com/narke/colorForth ) wich always worked with qemu up to version 2.5.1.1 but doesn't works from version 2.6 onwards. It continues to work with bochs.
+
+Downlaod: git clone https://github.com/narke/colorForth.git
+Build: make
+Test: qemu-system-i386 -drive format=raw,file=cf2012.img,index=0,if=floppy
+
+
+System information: Ubuntu LTS 16.04 x86-64
+Affected qemu versions: 2.6 to present (2.8)
+
+
+I got the message:
+
+
+WARNING: Image format was not specified for 'cf2012.img' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+qemu-system-i386: Trying to execute code outside RAM or ROM at 0x8998c426
+This usually means one of the following happened:
+
+(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
+(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
+(3) Your guest kernel has a bug and crashed by jumping off into nowhere
+
+This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
+If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.
+
+Execution cannot continue; stopping here.
+
+
+Thank you in advance.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1674114 b/results/classifier/gemma3:12b/boot/1674114
new file mode 100644
index 000000000..503ead4e1
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1674114
@@ -0,0 +1,28 @@
+
+Bad sectors when using MS-DOS 6.22
+
+When I try to install DOS 6.22 in QEMU, I get many disk errors when the virtual disk is beeing partionized and formatted. When I later do a SCANDISK, I can see many bad sectors and file errors.
+
+I have tested this with the following disk formats: qcow2, vmdk, raw.
+
+I tested this on Windows 7 with the following command line and QEMU version:
+qemu-system-i386 -name "Windows 3.11 WfW" -machine isapc -cpu 486 -boot order=adc -m 32 -soundhw sb16 -hda disk1.qcow2 -vga cirrus
+
+qemu-system-i386 --version
+QEMU emulator version 2.8.50 (v2.8.0-12557-g0bd1f6b1b2-dirty)
+Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
+
+I then did a test with the linux version of qemu, which gave me the same results.
+Command line: qemu-system-i386 -name "Windows 3.11 WfW" -machine isapc -cpu 486 -boot order=adc -m 32 -soundhw sb16 -hda disk1.qcow2 -vga cirrus -monitor stdout
+Version: qemu-system-i386 --version
+QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6), Copyright (c) 2003-2008 Fabrice Bellard
+
+I also checked the disk image with qemu-img, with no results:
+
+No errors were found on the image.
+7986/8000 = 99.83% allocated, 0.20% fragmented, 0.00% compressed clusters
+Image end offset: 523698176
+
+Because I got the error with two different versions of QEMU, I think this is a general problem and not related to a specific distribution.
+
+I have attached a zip file with screenshots of SCANDISK, which shows the disk errors.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1678 b/results/classifier/gemma3:12b/boot/1678
new file mode 100644
index 000000000..5ac2840fa
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1678
@@ -0,0 +1,9 @@
+
+Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.
+Description of problem:
+Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.
+Steps to reproduce:
+1.qemu-img.exe create hdd.img 10G
+2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso  -machine pc
+Additional information:
+both Use qemu v8.0 and qemu v8.1 to test, but failed also
diff --git a/results/classifier/gemma3:12b/boot/1679 b/results/classifier/gemma3:12b/boot/1679
new file mode 100644
index 000000000..35e29dffb
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1679
@@ -0,0 +1,16 @@
+
+Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.Enter the issue title
+Description of problem:
+Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work.
+Steps to reproduce:
+1.qemu-img.exe create hdd.img 10G
+
+2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso  -machine pc
+Additional information:
+both Use qemu v8.0 and qemu v8.1 to test, but failed also
+
+
+
+Thanks,
+
+Jianbin
diff --git a/results/classifier/gemma3:12b/boot/1689245 b/results/classifier/gemma3:12b/boot/1689245
new file mode 100644
index 000000000..d3f1e4771
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1689245
@@ -0,0 +1,9 @@
+
+qcow2 image converted from Photon OS can't be started
+
+Steps to reproduce the issue:
+1. Download the ovf from this place:
+https://bintray.com/vmware/photon/download_file?file_path=photon-custom-hw10-1.0-62c543d.ova
+2. Extract vmdk from ova file.
+3. Convert from vmdk fromat to qcow2 via qeum-img
+4. Launch the qcow2 image. The VM is started. But there is no any output. CPU usage is 100%
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1695286 b/results/classifier/gemma3:12b/boot/1695286
new file mode 100644
index 000000000..848d18d0e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1695286
@@ -0,0 +1,8 @@
+
+Add multiboot2 support
+
+multiboot2 is a recent specification that resolves some of the issues of multiboot. Multiboot2 is supported by some tools already (e.g. grub).
+
+It would be great if one can run OS with multiboot2 using '-kernel' option, similar as it is done now with multiboot images.
+
+Quick googling shows there is a Debian bug and patch that adds multiboot support https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621529 Would it be possible to integrate it to QEMU upstream?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1701 b/results/classifier/gemma3:12b/boot/1701
new file mode 100644
index 000000000..e486edebe
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1701
@@ -0,0 +1,6 @@
+
+-boot menu=on that vm is hangs
+Description of problem:
+virtual machine hangs, stop at press ESC for boot menu.
+Additional information:
+![qem-bootmenu](/uploads/423605d05b869c606bcd167e3934298d/qem-bootmenu.jpg)
diff --git a/results/classifier/gemma3:12b/boot/1704 b/results/classifier/gemma3:12b/boot/1704
new file mode 100644
index 000000000..b037d13a2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1704
@@ -0,0 +1,70 @@
+
+Booting arm64 Linux in TCG mode fails with "ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached"
+Description of problem:
+Linux seems to boot successfully, but around loading/executing userspace, QEMU crashes with an error:
+
+```
+[    4.047919] EXT4-fs (vda): mounted filesystem 59b147ee-5613-43a2-aab4-eaceb6e95be5 with ordered data mode. Quota mode: none.
+[    4.049630] VFS: Mounted root (ext4 filesystem) on device 254:0.
+[    4.055437] devtmpfs: mounted
+[    4.160039] Freeing unused kernel memory: 8256K
+[    4.161855] Run /sbin/init as init process
+[    4.547387] EXT4-fs (vda): re-mounted 59b147ee-5613-43a2-aab4-eaceb6e95be5. Quota mode: none.
+**
+ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached
+Bail out! ERROR:../tcg/tcg.c:4317:temp_load: code should not be reached
+zsh: abort      /home/mark/.opt/apps/qemu-v8.0.0-1645-ge6dd5e782b/bin/qemu-system-aarch64 -sm
+```
+Steps to reproduce:
+1. Run the provided qemu commandline
+2. Wait for QEMU to crash
+Additional information:
+I attempted a bisect, which suggests that the first bad commit is:
+
+```
+[e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r 
+```
+
+The full bisect log is:
+
+```
+[mark@lakrids:~/src/qemu]% git bisect log
+git bisect start
+# good: [f7f686b61cf7ee142c9264d2e04ac2c6a96d37f8] Update version for 8.0.2 release
+git bisect good f7f686b61cf7ee142c9264d2e04ac2c6a96d37f8
+# bad: [5f9dd6a8ce3961db4ce47411ed2097ad88bdf5fc] Merge tag 'pull-9p-20230608' of https://github.com/cschoenebeck/qemu into staging
+git bisect bad 5f9dd6a8ce3961db4ce47411ed2097ad88bdf5fc
+# good: [c1eb2ddf0f8075faddc5f7c3d39feae3e8e9d6b4] Update version for v8.0.0 release
+git bisect good c1eb2ddf0f8075faddc5f7c3d39feae3e8e9d6b4
+# good: [1a42d9d472b61e4db2fb16800495d402cb9b94af] tcg/sparc64: Split out tcg_out_movi_s32
+git bisect good 1a42d9d472b61e4db2fb16800495d402cb9b94af
+# good: [a30498fcea5a8b9c544324ccfb0186090104b229] tcg/riscv: Support CTZ, CLZ from Zbb
+git bisect good a30498fcea5a8b9c544324ccfb0186090104b229
+# good: [759573d05b808344f7047f893d2dd095884dfa4d] test-cutils: Add coverage of qemu_strtod
+git bisect good 759573d05b808344f7047f893d2dd095884dfa4d
+# good: [dc2a070d125772fe30384596d4d4ce6d9950b004] hw/arm/allwinner-r40: add Clock Control Unit
+git bisect good dc2a070d125772fe30384596d4d4ce6d9950b004
+# good: [c0dde5fc5ccce56b69095bc29af72987efd65d1e] accel/tcg: Fix undefined shift in store_whole_le16
+git bisect good c0dde5fc5ccce56b69095bc29af72987efd65d1e
+# bad: [e58e55dd8d5777f8a58ce30cfe04a8023282eb80] meson: fix "static build" entry in summary
+git bisect bad e58e55dd8d5777f8a58ce30cfe04a8023282eb80
+# bad: [5c13983e23de4095e2dfa8bc52333ef40ebe40db] target/arm: Sink gen_mte_check1 into load/store_exclusive
+git bisect bad 5c13983e23de4095e2dfa8bc52333ef40ebe40db
+# good: [6c4f229a2e0d6f882bae389ce0c5bdaea712ce0f] tests: avocado: boot_linux_console: Add test case for bpim2u
+git bisect good 6c4f229a2e0d6f882bae389ce0c5bdaea712ce0f
+# good: [e452ca5af88fc49b3026c2de0f1e65fd18d1a656] target/arm: Introduce finalize_memop_{atom,pair}
+git bisect good e452ca5af88fc49b3026c2de0f1e65fd18d1a656
+# good: [d450bd0157be43d273116c3e3617883c8a0ac3d1] target/arm: Use tcg_gen_qemu_{st, ld}_i128 for do_fp_{st, ld}
+git bisect good d450bd0157be43d273116c3e3617883c8a0ac3d1
+# bad: [e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r
+git bisect bad e6dd5e782becfe6d51f3575c086f5bd7162421d0
+# good: [e6073d88cc1fb43b00be16f79d9d6b0f9d2276f5] target/arm: Use tcg_gen_qemu_st_i128 for STZG, STZ2G
+git bisect good e6073d88cc1fb43b00be16f79d9d6b0f9d2276f5
+# first bad commit: [e6dd5e782becfe6d51f3575c086f5bd7162421d0] target/arm: Use tcg_gen_qemu_{ld, st}_i128 in gen_sve_{ld, st}r
+```
+
+Each build step was performed with:
+
+```
+ git clean -fdx && ./configure --prefix=/home/mark/.opt/apps/qemu-$(git describe --long HEAD) --enable-debug-info --disable-strip && make -j64 && make install
+```
diff --git a/results/classifier/gemma3:12b/boot/1706296 b/results/classifier/gemma3:12b/boot/1706296
new file mode 100644
index 000000000..988296a47
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1706296
@@ -0,0 +1,45 @@
+
+Booting NT 4 disk causes /home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())
+
+Grab the NT 4 disk from https://archive.org/details/Microsoft_Windows_NT_Server_Version_4.0_227-075-385_CD-KEY_419-1343253_1996
+
+Try to boot it as follows:
+
+qemu-system-x86_64 -hda disk.img -cdrom Microsoft_Windows_NT_Server_Version_4.0_227-075-385_CD-KEY_419-1343253_1996.iso -m 2048 -boot d -machine pc,accel=tcg
+WARNING: Image format was not specified for 'disk.img' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+**
+ERROR:/home/rjones/d/qemu/cpus.c:1580:qemu_mutex_lock_iothread: assertion failed: (!qemu_mutex_iothread_locked())
+Aborted (core dumped)
+
+The stack trace in the failing thread is:
+
+Thread 4 (Thread 0x7fffb0418700 (LWP 21979)):
+#0  0x00007fffdd89b64b in raise () at /lib64/libc.so.6
+#1  0x00007fffdd89d450 in abort () at /lib64/libc.so.6
+#2  0x00007fffdff8c75d in g_assertion_message () at /lib64/libglib-2.0.so.0
+#3  0x00007fffdff8c7ea in g_assertion_message_expr ()
+    at /lib64/libglib-2.0.so.0
+#4  0x00005555557a7d00 in qemu_mutex_lock_iothread ()
+    at /home/rjones/d/qemu/cpus.c:1580
+#5  0x00005555557cb429 in io_writex (env=env@entry=0x555556751400, iotlbentry=0x55555675b678, 
+    iotlbentry@entry=0x5aaaaae40c918, val=val@entry=8, addr=addr@entry=2148532220, retaddr=0, retaddr@entry=93825011136120, size=size@entry=4)
+    at /home/rjones/d/qemu/accel/tcg/cputlb.c:795
+#6  0x00005555557ce0f7 in io_writel (retaddr=93825011136120, addr=2148532220, val=8, index=255, mmu_idx=21845, env=0x555556751400)
+    at /home/rjones/d/qemu/softmmu_template.h:265
+#7  0x00005555557ce0f7 in helper_le_stl_mmu (env=env@entry=0x555556751400, addr=addr@entry=2148532220, val=val@entry=8, oi=<optimized out>, retaddr=93825011136120, retaddr@entry=0) at /home/rjones/d/qemu/softmmu_template.h:300
+#8  0x000055555587c0a4 in cpu_stl_kernel_ra (env=0x555556751400, ptr=2148532220, v=8, retaddr=0) at /home/rjones/d/qemu/include/exec/cpu_ldst_template.h:182
+#9  0x0000555555882610 in do_interrupt_protected (is_hw=<optimized out>, next_eip=<optimized out>, error_code=2, is_int=<optimized out>, intno=<optimized out>, env=0x555556751400) at /home/rjones/d/qemu/target/i386/seg_helper.c:758
+#10 0x0000555555882610 in do_interrupt_all (cpu=cpu@entry=0x555556749170, intno=<optimized out>, is_int=<optimized out>, error_code=2, next_eip=<optimized out>, is_hw=is_hw@entry=0) at /home/rjones/d/qemu/target/i386/seg_helper.c:1252
+#11 0x00005555558839d3 in x86_cpu_do_interrupt (cs=0x555556749170)
+    at /home/rjones/d/qemu/target/i386/seg_helper.c:1298
+#12 0x00005555557d2ccb in cpu_handle_exception (ret=<synthetic pointer>, cpu=0x5555566a4590) at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:465
+#13 0x00005555557d2ccb in cpu_exec (cpu=cpu@entry=0x555556749170)
+    at /home/rjones/d/qemu/accel/tcg/cpu-exec.c:670
+#14 0x00005555557a855a in tcg_cpu_exec (cpu=0x555556749170)
+    at /home/rjones/d/qemu/cpus.c:1270
+#15 0x00005555557a855a in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>)
+    at /home/rjones/d/qemu/cpus.c:1365
+#16 0x00007fffddc3d36d in start_thread () at /lib64/libpthread.so.0
+#17 0x00007fffdd975b9f in clone () at /lib64/libc.so.6
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1715700 b/results/classifier/gemma3:12b/boot/1715700
new file mode 100644
index 000000000..24c837515
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1715700
@@ -0,0 +1,27 @@
+
+Windows 7 guest won't boot on qemu 2.10 (works on 2.9)
+
+Qemu version: 2.10 stable.
+Guest: Windows 7 SP1 x64, virtio drivers are already installed in the guest.
+Command line:
+qemu-system-x86_64 \
+    -nodefaults \
+    -nodefconfig \
+    -machine type=q35,accel=kvm \
+    -enable-kvm \
+    -cpu host \
+    -m 2048 \
+    -vga virtio \
+    -boot menu=on \
+    -smbios file=/path/dmidecode_BIOS.bin \
+    -acpitable file=/path/acpi_slic.bin \
+    -bios /path/OVMF_CODE.fd \
+    -net none \
+    -drive if=virtio,media=disk,file=/media/win7.qcow2 \
+    -device pcie-root-port \
+    -device ich9-usb-ehci1 \
+    -device ich9-usb-uhci1 \
+    -device ich9-usb-uhci2 \
+    -device ich9-usb-uhci3
+
+Windows hangs at boot with waving flag screen (flag doesn't freeze, keeps waving indefinitely). Same command line boots fine with Qemu 2.9. I tried changing machine type to pc-q35-2.9 - same result.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1715715 b/results/classifier/gemma3:12b/boot/1715715
new file mode 100644
index 000000000..b0d3ec311
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1715715
@@ -0,0 +1,44 @@
+
+[qemu-ppc] Segfault when booting from HD after MacOS9 install
+
+I created an empty 128G qcow2 image and booted from a Mac OS 9.2.1 Install CD, in which I was able to install the OS successfully to the hard drive. Upon reboot, this time from the hard drive directly, qemu-system-ppc segfaults.
+
+qemu --version reports "v2.10.0-244-gb07d1c2-dirty", but I used git commit b07d1c2f5607489d4d4a6a65ce36a3e896ac065e and built with "./configure --target-list=ppc-softmmu --enable-debug --disable-strip".
+
+Here is the command-line arguments:
+
+qemu-system-ppc -boot c -g 1024x768x32 -M mac99 -m 256 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' -drive file=../os9.img,format=raw,media=cdrom -drive file=MacOS9.qcow2,format=qcow2,media=disk -spice port=5901,password=XXX -net nic,model=rtl8139 -net user -monitor stdio
+
+And the GDB backtrace:
+
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x0000559065fe7d3a in timer_mod (ts=0x0, expire_time=888960717010) at util/qemu-timer.c:462
+462         timer_mod_ns(ts, expire_time * ts->scale);
+[Current thread is 1 (Thread 0x7f60e43cb700 (LWP 9853))]
+(gdb) bt
+#0  0x0000559065fe7d3a in timer_mod (ts=0x0, expire_time=888960717010) at util/qemu-timer.c:462
+#1  0x0000559065d63769 in openpic_tmr_set_tmr (tmr=0x5590676fa7e0, val=96, enabled=true) at hw/intc/openpic.c:861
+#2  0x0000559065d63995 in openpic_tmr_write (opaque=0x5590676f71f0, addr=16, val=96, len=4) at hw/intc/openpic.c:912
+#3  0x0000559065b02811 in memory_region_write_accessor (mr=0x5590676f7710, addr=32, value=0x7f60e43c7da8, size=4, shift=0, mask=4294967295, attrs=...) at /home/bp/qemu/memory.c:529
+#4  0x0000559065b02a29 in access_with_adjusted_size (addr=32, value=0x7f60e43c7da8, size=1, access_size_min=4, access_size_max=4, access=0x559065b02727 <memory_region_write_accessor>, mr=0x5590676f7710, attrs=...) at /home/bp/qemu/memory.c:595
+#5  0x0000559065b051eb in memory_region_dispatch_write (mr=0x5590676f7710, addr=32, data=96, size=1, attrs=...) at /home/bp/qemu/memory.c:1337
+#6  0x0000559065aa3a36 in address_space_write_continue (as=0x559067614d90, addr=2147750160, attrs=..., buf=0x7f60e43c7ed0 "`_'\310`\177", len=1, addr1=32, l=1, mr=0x5590676f7710) at /home/bp/qemu/exec.c:2942
+#7  0x0000559065aa3b84 in address_space_write (as=0x559067614d90, addr=2147750160, attrs=..., buf=0x7f60e43c7ed0 "`_'\310`\177", len=1) at /home/bp/qemu/exec.c:2987
+#8  0x0000559065aa2ec0 in subpage_write (opaque=0x7f60c8275fc0, addr=272, value=96, len=1, attrs=...) at /home/bp/qemu/exec.c:2565
+#9  0x0000559065b02906 in memory_region_write_with_attrs_accessor (mr=0x7f60c8275fc0, addr=272, value=0x7f60e43c7fc8, size=1, shift=0, mask=255, attrs=...) at /home/bp/qemu/memory.c:555
+#10 0x0000559065b029d3 in access_with_adjusted_size (addr=272, value=0x7f60e43c7fc8, size=1, access_size_min=1, access_size_max=8, access=0x559065b02818 <memory_region_write_with_attrs_accessor>, mr=0x7f60c8275fc0, attrs=...) at /home/bp/qemu/memory.c:590
+#11 0x0000559065b0523a in memory_region_dispatch_write (mr=0x7f60c8275fc0, addr=272, data=96, size=1, attrs=...) at /home/bp/qemu/memory.c:1344
+#12 0x0000559065b175db in io_writex (env=0x7f60e43d42a0, iotlbentry=0x7f60e43e8130, mmu_idx=3, val=96, addr=2147750160, retaddr=140054158295744, size=1) at /home/bp/qemu/accel/tcg/cputlb.c:807
+#13 0x0000559065b18055 in io_writeb (env=0x7f60e43d42a0, mmu_idx=3, index=65, val=96 '`', addr=2147750160, retaddr=140054158295744) at /home/bp/qemu/softmmu_template.h:265
+#14 0x0000559065b181ea in helper_ret_stb_mmu (env=0x7f60e43d42a0, addr=2147750160, val=96 '`', oi=3, retaddr=140054158295744) at /home/bp/qemu/softmmu_template.h:300
+#15 0x00007f60e65ac2c0 in code_gen_buffer ()
+#16 0x0000559065b1ff26 in cpu_tb_exec (cpu=0x7f60e43cc010, itb=0x7f60e65ac5c0 <code_gen_buffer+935318>) at /home/bp/qemu/accel/tcg/cpu-exec.c:166
+#17 0x0000559065b20bfd in cpu_loop_exec_tb (cpu=0x7f60e43cc010, tb=0x7f60e65ac5c0 <code_gen_buffer+935318>, last_tb=0x7f60e43c8678, tb_exit=0x7f60e43c8674) at /home/bp/qemu/accel/tcg/cpu-exec.c:578
+#18 0x0000559065b20eed in cpu_exec (cpu=0x7f60e43cc010) at /home/bp/qemu/accel/tcg/cpu-exec.c:676
+#19 0x0000559065aebc3d in tcg_cpu_exec (cpu=0x7f60e43cc010) at /home/bp/qemu/cpus.c:1270
+#20 0x0000559065aebe64 in qemu_tcg_rr_cpu_thread_fn (arg=0x7f60e43cc010) at /home/bp/qemu/cpus.c:1365
+#21 0x00007f60f56f06ba in start_thread (arg=0x7f60e43cb700) at pthread_create.c:333
+#22 0x00007f60f542682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
+
+
+Any idea what is going on?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1716510 b/results/classifier/gemma3:12b/boot/1716510
new file mode 100644
index 000000000..357410c46
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1716510
@@ -0,0 +1,6 @@
+
+qemu 2.10.0 cannot boot Windows 10 familly
+
+On qemu 2.10.0 Windows 10 and Windows Server 2016 hangs during boot. Below is setup of Windows Server 2016. Downgrading to 2.9 fixes the problem.
+
+/usr/bin/qemu-system-x86_64 -name guest=<name>,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-<name>/master-key.aes -machine pc-q35-2.8,accel=kvm,usb=off,dump-guest-core=off -cpu host,nx=on,hv_relaxed,hv_vapic,hv_spinlocks=0x1000,hv_vpindex,hv_runtime,hv_synic,hv_reset,kvm=off -drive file=/usr/local/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd,if=pflash,format=raw,unit=0 -drive file=/var/lib/libvirt/qemu/nvram/<name>_VARS.fd,if=pflash,format=raw,unit=1 -m 4096 -realtime mlock=off -smp 12,sockets=1,cores=6,threads=2 -object iothread,id=iothread1 -object iothread,id=iothread2 -object iothread,id=iothread3 -object iothread,id=iothread4 -object iothread,id=iothread5 -object iothread,id=iothread6 -object iothread,id=iothread7 -object iothread,id=iothread8 -object iothread,id=iothread9 -object iothread,id=iothread10 -object iothread,id=iothread11 -object iothread,id=iothread12 -uuid <uuid> -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-<name>/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,clock=vm,driftfix=slew -no-shutdown -boot strict=on -device ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device ioh3420,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device ioh3420,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device ioh3420,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device ioh3420,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device ioh3420,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device nec-usb-xhci,id=usb,bus=pci.3,addr=0x0 -drive if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=2 -drive if=none,media=cdrom,id=drive-sata0-0-1,readonly=on -device ide-cd,bus=ide.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=1 -drive file=/dev/mapper/<boot disk>,format=raw,if=none,id=drive-sata0-0-2 -device ide-hd,bus=ide.2,drive=drive-sata0-0-2,id=sata0-0-2,bootindex=3 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=<mac>,bus=pci.1,addr=0x0 -netdev tap,fd=24,id=hostnet1,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=<mac>,bus=pci.2,addr=0x0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice unix,addr=/var/lib/libvirt/qemu/domain-2-<name>/spice.sock,disable-ticketing,image-compression=auto_glz,seamless-migration=on -vnc 127.0.0.1:0 -device qxl-vga,id=video0,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device vhost-scsi-pci,wwpn=<wwpn>,vhostfd=26,id=hostdev0,bus=pcie.0,addr=0x9 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1024,period=1000,bus=pci.5,addr=0x0 -msg timestamp=o
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1719282 b/results/classifier/gemma3:12b/boot/1719282
new file mode 100644
index 000000000..e0661b12d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1719282
@@ -0,0 +1,78 @@
+
+Unable to boot after drive-mirror
+
+Hi,
+I am using "drive-mirror" qmp block-job command to transfer VM disk image to other path (different physical disk on host).
+Unfortunately after shutting down and starting from new image, VM is unable to boot and qrub enters rescue mode displaying following error:
+```
+error: file '/grub/i386-pc/normal.mod' not found.
+Entering rescue mode...
+grub rescue>
+```
+
+To investigate the problem, I compared both RAW images using linux "cmp -l" command and found out that they differ in 569028 bytes starting from address 185598977 to 252708864 which are located on /boot partition.
+
+So I mounted /boot partition of mirrored RAW image on host OS and it seems that file-system is broken and grub folder is not recognized. But /boot on original RAW image has no problem.
+
+Mirrored Image:
+ls -l /mnt/vm-boot/
+ls: cannot access /mnt/vm-boot/grub: Structure needs cleaning
+total 38168
+-rw-r--r-- 1 root root   157721 Oct 19  2016 config-3.16.0-4-amd64
+-rw-r--r-- 1 root root   129281 Sep 20  2015 config-3.2.0-4-amd64
+d????????? ? ?    ?           ?            ? grub
+-rw-r--r-- 1 root root 15739360 Nov  2  2016 initrd.img-3.16.0-4-amd64
+-rw-r--r-- 1 root root 12115412 Oct 10  2015 initrd.img-3.2.0-4-amd64
+drwxr-xr-x 2 root root    12288 Oct  7  2013 lost+found
+-rw-r--r-- 1 root root  2679264 Oct 19  2016 System.map-3.16.0-4-amd64
+-rw-r--r-- 1 root root  2114662 Sep 20  2015 System.map-3.2.0-4-amd64
+-rw-r--r-- 1 root root  3126448 Oct 19  2016 vmlinuz-3.16.0-4-amd64
+-rw-r--r-- 1 root root  2842592 Sep 20  2015 vmlinuz-3.2.0-4-amd64
+
+Original Image:
+ls /mnt/vm-boot/ -l
+total 38173
+-rw-r--r-- 1 root root   157721 Oct 19  2016 config-3.16.0-4-amd64
+-rw-r--r-- 1 root root   129281 Sep 20  2015 config-3.2.0-4-amd64
+drwxr-xr-x 5 root root     5120 Nov  2  2016 grub
+-rw-r--r-- 1 root root 15739360 Nov  2  2016 initrd.img-3.16.0-4-amd64
+-rw-r--r-- 1 root root 12115412 Oct 10  2015 initrd.img-3.2.0-4-amd64
+drwxr-xr-x 2 root root    12288 Oct  7  2013 lost+found
+-rw-r--r-- 1 root root  2679264 Oct 19  2016 System.map-3.16.0-4-amd64
+-rw-r--r-- 1 root root  2114662 Sep 20  2015 System.map-3.2.0-4-amd64
+-rw-r--r-- 1 root root  3126448 Oct 19  2016 vmlinuz-3.16.0-4-amd64
+-rw-r--r-- 1 root root  2842592 Sep 20  2015 vmlinuz-3.2.0-4-amd64
+
+ls /mnt/vm-boot/grub/ -l
+total 2376
+-rw-r--r-- 1 root root      48 Oct  7  2013 device.map
+drwxr-xr-x 2 root root    1024 Oct 10  2015 fonts
+-r--r--r-- 1 root root    9432 Nov  2  2016 grub.cfg
+-rw-r--r-- 1 root root    1024 Oct  7  2013 grubenv
+drwxr-xr-x 2 root root    6144 Aug  6  2016 i386-pc
+drwxr-xr-x 2 root root    1024 Aug  6  2016 locale
+-rw-r--r-- 1 root root 2400500 Aug  6  2016 unicode.pf2
+
+qemu Version: 2.7.0-10
+
+Host OS: Debian 8x64
+Guest OS: Debian 8x64
+
+QMP Commands log:
+socat UNIX-CONNECT:/var/run/qemu-server/48016.qmp STDIO
+{"QMP": {"version": {"qemu": {"micro": 0, "minor": 7, "major": 2}, "package": "pve-qemu-kvm_2.7.0-10"}, "capabilities": []}}
+{ "execute": "qmp_capabilities" }
+{"return": {}}
+{ "execute": "drive-mirror",
+  "arguments": {
+    "device": "drive-ide0",
+    "target": "/diskc/48016/vm-48016-disk-2.raw",
+    "sync": "full",
+    "mode": "absolute-paths",
+    "speed": 0
+  }
+}
+{"return": {}}
+{"timestamp": {"seconds": 1506331591, "microseconds": 623095}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-ide0", "len": 269445758976, "offset": 269445758976, "speed": 0, "type": "mirror"}}
+{"timestamp": {"seconds": 1506332641, "microseconds": 245272}, "event": "SHUTDOWN"}
+{"timestamp": {"seconds": 1506332641, "microseconds": 377751}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-ide0", "len": 271707340800, "offset": 271707340800, "speed": 0, "type": "mirror"}}
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1719689 b/results/classifier/gemma3:12b/boot/1719689
new file mode 100644
index 000000000..7bcc49268
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1719689
@@ -0,0 +1,15 @@
+
+[feature request] add flag to treat warnings as errors
+
+Since booting could potentially take a lot of time and warnings are likely to indicate that something is wrong, it would be useful to have a command line flag which would abort the boot if there are any warnings.
+
+An example might be network configuration. The following output most likely indicates that there is something the user has to fix before starting and being able to use the guest os. 
+
+Warning: hub port hub0port0 has no peer
+Warning: vlan 0 with no nics
+Warning: netdev hub0port0 has no peer
+Warning: requested NIC (anonymous, model vitrio-net-device) was not created (not supported by this machine?)
+
+Ideally, there would be an option the user could pass which would cause qemu to print these warnings then exit, rather than boot the kernel.
+
+Alternatively, or additionally, a dry run option would be helpful for the same purpose: making sure qemu get to the booting the kernel stage with everything in working order so that you do not have to wait for the kernel to boot and then shut down while debugging things like networking (things which can be debugged (at least partially) without booting, or trying to boot, the guest os).
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1723927 b/results/classifier/gemma3:12b/boot/1723927
new file mode 100644
index 000000000..0e4d7debf
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1723927
@@ -0,0 +1,18 @@
+
+Linux or windows guest boot failed by uefi  on CPU of  Intel Xeon X5675
+
+Hi,
+
+I started windows server 2012 DC or redhat7.0, but boot failed by UEFI, and start process stop on
+"TianoCore" image by looking at VNCviewer.
+
+VM using the command:(redhat7.0)
+/usr/bin/kvm -name guest=ytest,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/run/lib/libvirt/qemu/domain-40-ytest/master-key.aes -machine pc-i440fx-2.7,accel=kvm,usb=off,system=windows,dump-guest-core=off -bios /usr/share/qemu-kvm/OVMF_CODE.fd -m size=8388608k,slots=10,maxmem=34359738368k -realtime mlock=off -smp 1,maxcpus=24,sockets=24,cores=1,threads=1 -numa node,nodeid=0,cpus=0-23,mem=8192 -uuid 8cf40bd6-258a-4550-ba4e-b38230547a11 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -chardev socket,id=charmonitor_cas,path=/run/lib/libvirt/qemu/domain-40-ytest/monitor.sock.cas,server,nowait -mon chardev=charmonitor_cas,id=monitor_cas,mode=control -rtc base=utc -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-ehci,id=usb1,bus=pci.0,addr=0x3 -device nec-usb-xhci,id=usb2,bus=pci.0,addr=0x4 -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x6 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -device usb-hub,id=hub0,bus=usb.0,port=1 -drive file=/vms/hw235/ytest,format=qcow2,if=none,id=drive-virtio-disk0,cache=directsync,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,pci_hotpluggable=on,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,id=drive-fdc0-0-0,readonly=on -global isa-fdc.driveA=drive-fdc0-0-0 -global isa-fdc.bootindexA=2 -netdev tap,fd=48,id=hostnet0,vhost=on,vhostfd=50 -device virtio-net-pci,pci_hotpluggable=on,netdev=hostnet0,id=net0,mac=0c:da:41:1d:67:6f,bus=pci.0,addr=0x5,bootindex=4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/ytest.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -vnc 0.0.0.0:9 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -msg timestamp=on
+
+qemu version: 2.7.1
+edk2 version: git://git.code.sf.net/p/tianocore/edk2.git, commit: cc0b456a05f8dd1ebfb9be485465be37e96999e7
+server: ProLiant BL460c G7, CPU: Intel(R) Xeon(R) CPU X5675  @ 3.07GHz
+
+Another, last version of edk2(compiled by myself) start guest is failed, too. But r15214 of edk2 start guest is ok(Download from http://sourceforge.net/projects/edk2/files/OVMF/, OVMF-X64-r15214.zip)
+
+Thanks in Advance
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1732679 b/results/classifier/gemma3:12b/boot/1732679
new file mode 100644
index 000000000..9db8dcf17
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1732679
@@ -0,0 +1,89 @@
+
+Cisco NX-OSv 9k crashes during boot with qemu 2.10.1(Debian 1:2.10.0+dfsg-2) and ovmf 0~20161202.7bbe0b3e-1
+
+Ubuntu 17.04
+qemu 2.10.1(Debian 1:2.10.0+dfsg-2)
+gns3 2.0.3
+NX-OSv 9k 7.0.3.I6.1
+
+- No such issue with previous qemu 2.8.x
+- the issue does not seem to come from the debian packaging
+- the issue does not seem to come from GNS3 either, as confirmed by Jeremy Grossmann at https://github.com/GNS3/gns3-server/issues/1193#issuecomment-344240460
+
+Either some parameters usage have changed (for instance -bios) (which would make qemu not backwards compatible) or there is an issue with qemu itself.
+The configuration parameters are:
+```
+                "compute_id": "local",
+                "console": 2010,
+                "console_type": "telnet",
+                "first_port_name": "mgmt0",
+                "height": 48,
+                "label": {
+                    "rotation": 0,
+                    "style": "font-family: TypeWriter;font-size: 10.0;font-weight: bold;fill: #000000;fill-opacity: 1.0;",
+                    "text": "NX_OSv_9k_Spine_31",
+                    "x": -54,
+                    "y": -25
+                },
+                "name": "NX_OSv_9k_Spine_31",
+                "node_id": "8d01119a-0adc-41bc-950b-c5639db7708c",
+                "node_type": "qemu",
+                "port_name_format": "Ethernet1/{port1}",
+                "port_segment_size": 0,
+                "properties": {
+                    "acpi_shutdown": false,
+                    "adapter_type": "e1000",
+                    "adapters": 10,
+                    "bios_image": "",
+                    "bios_image_md5sum": null,
+                    "boot_priority": "c",
+                    "cdrom_image": "",
+                    "cdrom_image_md5sum": null,
+                    "cpu_throttling": 0,
+                    "cpus": 2,
+                    "hda_disk_image": "NX-OSv-9k-7.0.3.I6.1.free.qcow2",
+                    "hda_disk_image_md5sum": "18bb991b814a508d1190575f99deed99",
+                    "hda_disk_interface": "ide",
+                    "hdb_disk_image": "",
+                    "hdb_disk_image_md5sum": null,
+                    "hdb_disk_interface": "ide",
+                    "hdc_disk_image": "",
+                    "hdc_disk_image_md5sum": null,
+                    "hdc_disk_interface": "ide",
+                    "hdd_disk_image": "",
+                    "hdd_disk_image_md5sum": null,
+                    "hdd_disk_interface": "ide",
+                    "initrd": "",
+                    "initrd_md5sum": null,
+                    "kernel_command_line": "",
+                    "kernel_image": "",
+                    "kernel_image_md5sum": null,
+                    "legacy_networking": false,
+                    "mac_address": "00:07:00:03:16:01",
+                    "options": "-nographic -enable-kvm -cpu host -machine q35 -smp cpus=2 -bios /usr/share/ovmf/OVMF.fd",
+                    "platform": "x86_64",
+                    "process_priority": "normal",
+                    "qemu_path": "/usr/bin/qemu-system-x86_64",
+                    "ram": 6144,
+                    "usage": ""
+```
+
+The logs are:
+- [execution log](https://github.com/GNS3/gns3-server/files/1381651/qemu.log.txt)
+- [terminal log](https://github.com/GNS3/gns3-server/files/1381660/terminal.log.txt)
+
+With the latest qemu, I can boot:
+- Cisco IOSv 15.6(2)T
+- Cisco IOSv-L2 15.2(20170321:233949)
+- Cisco CSR 1000v 16.5.1b
+- Cisco ASAv 9.6(2)
+
+The major difference with NX-OSv 9k is the bios parameter: ```-bios /usr/share/ovmf/OVMF.fd```: 
+```
+ll /usr/share/ovmf/OVMF.fd
+-rw-r--r-- 1 root root 2097152 Dec  9  2016 /usr/share/ovmf/OVMF.fd
+```
+A normal boot log with qemu 2.8.1 is available [here](https://github.com/GNS3/gns3-server/files/1381729/terminal.log.2.8.txt)
+
+Highlighting the differences: qemu 2.8.1 on the left, qemu 2.10.1 on the right hand side with the same boot parameters
+![qemu 2 8 vs qemu 2 10](https://user-images.githubusercontent.com/13176858/31534998-8429462e-aff9-11e7-9cf3-bf2b00c21e8a.jpg)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1734474 b/results/classifier/gemma3:12b/boot/1734474
new file mode 100644
index 000000000..35f304b5d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1734474
@@ -0,0 +1,5 @@
+
+Maemo does not boot on emulated N800
+
+I start QEMU with qemu-system-arm-m 130 -M n800 -kernel zImage.1 -mtdblock maemo.img -append "root=/dev/mtdblock3 rootfstype=jffs2"
+On QEMU 1.2.0 see "NOKIA" logo and then desktop appears, but on 1.5.0 and newer (including latest versions) I see only white screen and no signs of life. Was this caused by regression or any syntax change?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1735653 b/results/classifier/gemma3:12b/boot/1735653
new file mode 100644
index 000000000..fe7fc2853
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1735653
@@ -0,0 +1,41 @@
+
+qemu aarch64 cannot boot linux kernel v4.6+
+
+Hi,
+I tested the latest qemu-system-aarch64 cannot boot linux mainline kernel since v4.6 from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git.
+
+Environment info:
+# host
+ ubuntu 16.04
+# qemu
+ Master branch from git://git.qemu.org/qemu.git, and now the HEAD is c11d61271b9e6e7a1f0479ef1ca8fb55fa457a62.
+# build command
+ ./configure --target-list=aarch64-softmmu
+ make
+# qemu commmand
+ qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine type=virt -smp 4 -m 1024 -nographic -s -kernel ~/workspace/linux/arch/arm64/boot/Image -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::2222-:22
+
+Error info:
+ No error prompted, actually no any log which means I couldn't see the usually kernel boot message.
+
+Debug info:
+ I did a git bisect on linux, and found with this kernel commit, qemu failed to boot. Parent of 406e308770a92bd33995b2e5b681e86358328bb0 can boot.
+ commit 406e308770a92bd33995b2e5b681e86358328bb0
+    Author: James Morse <email address hidden>
+    Date:   Fri Feb 5 14:58:47 2016 +0000
+
+    arm64: add ARMv8.2 id_aa64mmfr2 boiler plate
+
+    ARMv8.2 adds a new feature register id_aa64mmfr2. This patch adds the
+    cpu feature boiler plate used by the actual features in later patches.
+
+    Signed-off-by: James Morse <email address hidden>
+    Reviewed-by: Suzuki K Poulose <email address hidden>
+    Signed-off-by: Catalin Marinas <email address hidden>
+ The main change in the patch is to add reg_id_aa64mmfr2 in to arch/arm64/include/asm/cpu.h, so might it be any struct change not included in qemu?
+
+Can you please help check how to fix it?
+
+Thanks
+
+- Joey
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1736042 b/results/classifier/gemma3:12b/boot/1736042
new file mode 100644
index 000000000..f318f098b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1736042
@@ -0,0 +1,20 @@
+
+qemu-system-x86_64 does not boot image reliably
+
+Booting image as root user with following command works randomly.
+
+./qemu-system-x86_64 -enable-kvm -curses -smp cpus=4 -m 8192 /root/ructfe2917_g.qcow2
+
+Most of the time it ends up on "800x600 Graphic mode"(been stuck there even for 4 hours before killed), but 1 out of ~20 it boots image correctly(and instantly).
+
+This is visible in v2.5.0 build from sources, v2.5.0 from Ubuntu Xenial and v2.1.2 from Debian Jessie.
+
+The image in question was converted from vmdk using:
+
+qemu-img convert -O qcow2 file.vmdk file.qcow2
+
+The image contains Ubuntu with grub.
+
+I can provide debug logs, but will need guidance how to enable them(and what logs are necessary).
+
+As a side note, it seems that booting is more certain after connecting(or mounting) partition using qemu-nbd/mount.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1737194 b/results/classifier/gemma3:12b/boot/1737194
new file mode 100644
index 000000000..5e2c44e76
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1737194
@@ -0,0 +1,37 @@
+
+Windows NT 4.0 fails to boot from qcow2 installation
+
+Windows NT 4.0 will not boot from an installation more than once if installed in a qcow2 image file. A quick fix to this problem is to use the qcow format instead.
+
+Steps to reproduce this issue:
+
+Create the image file:
+qemu-img create -f qcow2 winnt4.qcow2 1G
+
+Boot from a Windows NT 4.0 Workstation CD:
+qemu-system-i386 -hda winnt4.qcow2 -cdrom /dev/cdrom -boot d -m 128 -cpu pentium -vga cirrus
+
+During the installation process you have the choise between FAT and NTFS. You can pick anyone.
+
+After finishing the installation the guest will reboot to install additional items. Once this is done the guest will be bootable. Eject any CD media from QEMU and reboot. You will then see Windows NT 4.0 booting up to the desktop. Go to "Start->Shut down" to shut down. Then when Windows is ready quit QEMU. 
+
+Now try to boot using this command:
+qemu-system-i386 -hda winnt4.qcow2 -boot c -m 128 -cpu pentium -vga cirrus 
+ 
+The BIOS screen will display an error message:
+
+For NTFS: 
+Booting from Hard Disk...
+A disk read error occurred.
+Insert a system diskette and restart
+the system.
+
+For FAT:
+No bootable device.
+
+Additional information:
+qemu-system-i386 version: 2.10.1
+qemu-img version: 2.10.92 (v2.11.0-rc4-dirty)
+
+If you don't have a Windows NT 4.0 Workstation installation CD, you may download one from here:
+https://winworldpc.com/product/windows-nt-40/40
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1737882 b/results/classifier/gemma3:12b/boot/1737882
new file mode 100644
index 000000000..cd285cf38
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1737882
@@ -0,0 +1,5 @@
+
+QEMU Zaurus cannot boot 2.4.x kernels
+
+I tried akita and spitz machines.
+4.x, 3.x and 2.6.x kernels boot OK, but when I try to pass any 2.4.x, qemu crashes with "Trying to execute code outside RAM or ROM at 0x00800000".
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1737883 b/results/classifier/gemma3:12b/boot/1737883
new file mode 100644
index 000000000..771739e85
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1737883
@@ -0,0 +1,7 @@
+
+Cannot boot FreeBSD on versatilepb machine
+
+I know some years ago it was possible to boot FreeBSD in QEMU versatilepb machine
+https://kernelnomicon.org/?p=229 (you can download image and kernel using web.archive.org)
+Now when I try to do that I get only black screen with no output even in QEMU console.
+I also added -global versatile_pci.broken-irq-mapping=1, but this seem to have no effect.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1738507 b/results/classifier/gemma3:12b/boot/1738507
new file mode 100644
index 000000000..c68f9510d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1738507
@@ -0,0 +1,10 @@
+
+qemu sometimes stuck when booting windows 10
+
+I am using qemu-2.10.1, or actually libvirt, to create a virtual machine, running microsoft windows 10 pro operating system.
+It installed fine and was actually working, however sometimes when trying to boot the vm, the whole boot process gets stuck.
+For some reason, it seemed to happen only when enough physical memory is taken so that, when booting a windows vm that has 4gb of available ram, host starts swapping some other processes. It is not always happening there, but often it happens, and I do not remember seeing any case of this happening when not swapping, maybe a kind of a timing issue?
+When this happens, I usually try to hard reset the machine by libvirt reset command or equivalent system_reset on qemu monitor, however the whole reset does not happen, and the command is a noop. That makes me think it is a qemu bug, not windows refusing operation. At the time of this event, qemu monitor and spice server are working correctly, are not stuck, and even doing things like system reset does not result in a monitor hang. It is also possible to quit qemu normally.
+I tried to workaround the bug by guessing what may cause it. Switched from bios to uefi, changed virtio-scsi to ahci temporarily, and disabled virtio-balloon in case it would be buggy, with no visible change.
+I will attach a libvirt log, because it contains qemu command line. I will also attach an example qemu backtrace.
+From what i know, both vcpu threads are working normally, at least none of them is stuck in a vcpu, nor deadlocked, etc. So backtrace could be different each time I tried to get it.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1738771 b/results/classifier/gemma3:12b/boot/1738771
new file mode 100644
index 000000000..dcc02961b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1738771
@@ -0,0 +1,20 @@
+
+qemu user does not provide AT_SECURE auxiliary vector entry
+
+When executing an android native binary using qemu in user mode, the program fail with the message
+
+FATAL: kernel did not supply AT_SECURE
+
+Android uses bionic libc.The linker requires that AT_SECURE is provided in the auxiliary vector, but qemu does not provide the entry.
+
+The issue can be reproduced using the commands:
+
+mkdir -p /tmp/android/system
+cd /tmp/android
+curl -O https://dl.google.com/android/repository/sys-img/google_apis/sysimg_x86-21_r15.zip
+unzip sysimg_x86-21_r15.zip
+mount -o loop x86/system.img system
+qemu-i386 -L /tmp/android/ system/bin/ls
+
+
+I've provided a patch (https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03667.html) to fix the issue, but it was not reviewed yet.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1738840 b/results/classifier/gemma3:12b/boot/1738840
new file mode 100644
index 000000000..2140c91ab
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1738840
@@ -0,0 +1,86 @@
+
+qemu-img convert qcow2 to raw fails on OS X
+
+I try to convert a image from qcow2 to raw and the result is a not bootable image.
+I dont know if it is a bug in qemu-img convert or with the image it self.
+
+See this error report for better readability:
+https://github.com/coreos/bugs/issues/1121#issuecomment-351968518
+
+As a reply here they use 2.9.0 version of 
+
+
+$ qemu-img -V
+qemu-img version 2.11.0
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+$ uname -v
+Darwin Kernel Version 17.2.0
+
+$ mount ./
+/dev/disk1s1 on / (apfs, local, journaled)
+
+$  wget https://beta.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2
+
+$ date
+Fri Dec 14 17:15:57 CET 2017
+
+$ bunzip2 coreos_production_openstack_image.img.bz2
+
+
+$ cp -a coreos_production_openstack_image.img.org coreos_production_openstack_image.img
+
+$ shasum coreos_production_openstack_image.img.org
+ae2119c6f0390dc36f247f7016923ea85de5d8e6  coreos_production_openstack_image.img.org
+
+$ qemu-img convert -f qcow2 -O raw coreos_production_openstack_image.img.org coreos_production_openstack_image.bin
+
+$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.img -boot c
+SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org)
+
+
+iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980
+                                                                               
+
+
+Booting from Hard Disk...
+GRUB loading....
+Welcome to GRUB!
+....
+
+$ qemu-system-x86_64 -m 256 -nographic -hda coreos_production_openstack_image.bin -boot c
+
+SeaBIOS (version rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org)
+
+
+iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF915A0+0FEF15A0 C980
+                                                                               
+
+
+Booting from Hard Disk...
+Boot failed: not a bootable disk
+....
+
+
+$ head -c 8192 coreos_production_openstack_image.bin | hexdump -C
+00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
+*
+00002000
+
+$ qemu-img info coreos_production_openstack_image.bin
+image: coreos_production_openstack_image.bin
+file format: raw
+virtual size: 8.5G (9116319744 bytes)
+disk size: 217M
+
+$ qemu-img info coreos_production_openstack_image.img
+image: coreos_production_openstack_image.img
+file format: qcow2
+virtual size: 8.5G (9116319744 bytes)
+disk size: 785M
+cluster_size: 65536
+Format specific information:
+    compat: 0.10
+    refcount bits: 16
+
+The same version works on Ubuntu so it looks like its only the Mac version or the new APFS filesystem.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1743191 b/results/classifier/gemma3:12b/boot/1743191
new file mode 100644
index 000000000..a38739fbd
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1743191
@@ -0,0 +1,42 @@
+
+Interacting with NetBSD serial console boot blocks no longer works
+
+The NetBSD boot blocks display a menu allowing the user to make a
+selection using the keyboard.  For example, when booting a NetBSD
+installation CD-ROM, the menu looks like this:
+
+         1. Install NetBSD
+         2. Install NetBSD (no ACPI)
+         3. Install NetBSD (no ACPI, no SMP)
+         4. Drop to boot prompt
+
+    Choose an option; RETURN for default; SPACE to stop countdown.
+    Option 1 will be chosen in 30 seconds.
+
+When booting NetBSD in a recent qemu using an emulated serial console,
+making this menu selection no longer works: when you type the selected
+number, the keyboard input is ignored, and the 30-second countdown
+continues.  In older versions of qemu, it works.
+
+To reproduce the problem, run:
+
+   wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-7.1.1/amd64/installation/cdrom/boot-com.iso
+   qemu-system-x86_64 -nographic -cdrom boot-com.iso
+
+During the 30-second countdown, press 4
+
+Expected behavior: The countdown stops and you get a ">" prompt
+
+Incorrect behavior: The countdown continues
+
+There may also be some corruption of the terminal output; for example,
+"Option 1 will be chosen in 30 seconds" may be displayed as "Option 1
+will be chosen in p0 seconds".
+
+Using bisection, I have determined that the problem appeared with qemu
+commit 083fab0290f2c40d3d04f7f22eed9c8f2d5b6787, in which seabios was
+updated to 1.11 prerelease, and the problem is still there as of
+commit 7398166ddf7c6dbbc9cae6ac69bb2feda14b40ac.  The host operating
+system used for the tests was Debian 9 x86_64.
+
+Credit for discovering this bug goes to Paul Goyette.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1743441 b/results/classifier/gemma3:12b/boot/1743441
new file mode 100644
index 000000000..18fde92cc
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1743441
@@ -0,0 +1,4 @@
+
+OS/2 Warp 4.52 OS2LVM failure
+
+When I try to boot OS/2 Warp 4.51 (Merlin), 4.52 (Aurora) or eCS 1.2.5, etc. I always get an exception in OS2LVM (TRAP 000E). You can reproduce the bug using this disk image: https://drive.google.com/open?id=1zzjs9hTS0TK-Xb5hnon8SQ-2C1EmlYfy
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1745 b/results/classifier/gemma3:12b/boot/1745
new file mode 100644
index 000000000..83268a713
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1745
@@ -0,0 +1,68 @@
+
+qemu-system-sparc64 v8.0.2 failed to read the file system.
+Steps to reproduce:
+1. Run qemu-system-sparc64 with the following command line.
+  `qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2`
+2. The system will report a issue "Could not open option rom 'pflash0': No such file or directory"
+3. Then, enter the boot command on the boot loader.
+4. The command failed with following message.
+```
+Boot device: vdisk  File and args:
+Bad magic number in disk label
+Can't open disk label package
+
+Can't open boot device
+```
+Additional information:
+```
+$ qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2
+Could not open option rom 'pflash0': No such file or directory
+cpu Probing I/O buses
+
+
+Sun Fire T2000, No Keyboard
+Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
+OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
+[mo23723 obp4.20.0 #0]
+Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
+
+
+
+ok boot
+Boot device: vdisk  File and args:
+Bad magic number in disk label
+Can't open disk label package
+
+Can't open boot device
+
+ok
+```
+
+It works fine with the previous qemu-system-sparc64 version.
+
+```
+$ qemu-7.2.3/build/qemu-system-sparc64 -M niagara -L S10image/ -nographic -m 256 -drive if=pflash,readonly=on,file=S10image/disk.s10hw2
+cpu Probing I/O buses
+
+
+Sun Fire T2000, No Keyboard
+Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
+OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.
+[mo23723 obp4.20.0 #0]
+Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.
+
+
+
+ok boot
+Boot device: vdisk  File and args:
+Loading ufs-file-system package 1.4 04 Aug 1995 13:02:54.
+FCode UFS Reader 1.12 00/07/17 15:48:16.
+Loading: /platform/SUNW,Sun-Fire-T2000/ufsboot
+Loading: /platform/sun4v/ufsboot
+SunOS Release 5.10 Version Generic_118822-23 64-bit
+Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
+Use is subject to license terms.
+Hostname: unknown
+
+unknown console login:
+```
diff --git a/results/classifier/gemma3:12b/boot/1745312 b/results/classifier/gemma3:12b/boot/1745312
new file mode 100644
index 000000000..3e1dc3e03
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1745312
@@ -0,0 +1,590 @@
+
+Regression report: Disk subsystem I/O failures/issues surfacing in DOS/early Windows [two separate issues: one bisected, one root-caused]
+
+[Headsup: This report is long-ish due to the amount of detail I've stumbled on along the way that I think is relevant to include. I can't speak as to the complexity of the actual bugs, but the size of this report should not suggest that the reproduction process is particularly headache-inducing.]
+
+Hi!
+
+I recently needed to fire up some ancient software for research purposes and got very distracted discovering and playing with old versions of Windows :). In the process I've discovered some glitches with disk I/O.
+
+I believe I've stumbled on two completely separate issues that coincidentally surfaced at the same time. It's possible that components of this report will be re-filed as more specific new bugs, but I'm not an authority on QEMU internals or how to narrow down/categorize what I've found.
+
+- The first bug only surfaces when the "isapc" machine type is used. It intermittently produces "General failure {read,writ}ing drive _" under MS-DOS 6.22, and also somehow interferes with early bootstrap of Windows NT 4 (in NTLDR). Enabling or disabling KVM (I'm on Linux) appears to make no difference whatsoever, which may help with debugging.
+
+- The second issue involves
+  - a WinNT4 disk image
+  - created by running through a bog-standard NT4 install inside QEMU 2.9.0
+  - which will now fail to boot in any version of QEMU - even version 1.0
+    - but which VirtualBox will boot fine
+      - but only if I point VirtualBox at QEMU's raw disk image via a
+        hacked-together VMDK file
+      - if the raw image is converted to VHD(X), VirtualBox will also fail
+        to boot the image with exactly the same error as QEMU
+      - this state of affairs is not affected by image sparseness (which makes
+        sense)
+
+I'm confident I've bisected the first issue.
+
+I wasn't able to bisect the second issue (as all tested versions of QEMU behaved identically), but I've figured out a working repro testcase and I believe I've managed to pin down a solid root cause.
+
+
+
+== #1: Intermittent I/O issues when `-M isapc` is used =====
+
+These symptoms sometimes take a small amount of time and fiddling to trigger, but I AM able to consistently surface them on my machine after a short while. (I am very very interested to hear if others cannot reproduce them.)
+
+So, first of all:
+
+https://github.com/qemu/qemu/commit/306ec6c3cece7004429c79c1ac93d49919f1f1cc
+  (Jul 30 2013): the last version that works
+
+https://github.com/qemu/qemu/commit/e689f7c668cbd9d08f330e17c3dd3a059c9553d3
+  (Oct 30 2013): the first version that intermittently fails
+
+Maybe lift out and build these branches while reading. *shrug*
+(How to do this can be found at the end of this report - along with a time-saving ./configure line, FWIW)
+
+Here are the changelists between these two revisions:
+
+https://github.com/qemu/qemu/compare/306ec6c...e689f7c
+(Compare direction: OLD to NEW) (Commits: 166  Files changed: 192)
+
+https://github.com/qemu/qemu/compare/e689f7c...306ec6c
+(Compare direction: NEW to OLD) (Commits: 30   Files changed: 22)
+
+(Someone else more familiar with Git might know why GitHub returns results for both compare directions, and/or if the 2nd link is useful information. The first link returns a lot more results than the 2nd one, at least. Does comparing new>old return deletions?)
+
+---
+
+Now on to the symptoms. In a moment I'll describe reproduction.
+
+# MS-DOS 6.22
+
+The first symptom I discovered was that trivial read and write operations under MS-DOS would sometimes fail:
+
+  C:\>echo test > hi
+
+  General failure writing drive C
+  Abort, Retry, Fail?
+
+Anything else that exercises the disk behaves similarly:
+
+  C:\>dir /s > nul
+
+  General failure reading drive C
+  Abort, Retry, Fail?
+
+(Note that the above demonstrates both write and read failures)
+
+(Also, FWIW, `dir /s` == `ls -R`)
+
+The behavior of the I/O errors is not possible to characterise as it fluctuates so much. For example something as simple as DIR can produce wildly differing results: in one run, poking around with DIR ended with DOS deciding C:\ was empty at one point; at another point in a different run C:\ mysteriously dropped 50% of its contents only to magically gain it all back moments later after some poking around in one of the subdirectories that was still visible.
+
+The time it takes to trigger these errors is also highly variable. QEMU may fall over as early as hanging forever at "Starting MS-DOS...", or I might get all the way into Windows 3.1 before it triggers (in which case Win3.1 reports vague memory errors - of all things).
+
+Very occasionally I've seen _SeaBIOS itself_ report "Booting from Hard Disk..." "Boot failed: could not read the boot disk" ... "No bootable device.", and on one occasion I even got "Non-System disk or disk error" "Replace and strike any key when ready"!
+
+
+# WinNT 4 Terminal Server
+
+Most of the time, NTLDR will fire up normally. But every so often...
+
+  SeaBIOS (version rel-1.7.3-117-g31b8b4e-20131206_080705-nilsson.home.kraxel.org)
+
+  Booting from Hard Disk...
+  A disk read error occurred.
+  Insert a system diskette and restart
+  the system.
+
+(NB. You're seeing the old SeaBIOS version included with e689f7c, which was the first buggy commit.)
+
+If NT gets past this point without erroring out (ie, it makes it to the boot menu), the rest of the system is 100% fine and there are no other disk I/O issues whatsoever. For example, on QEMU 2.9.0 I was able to enable disk compression, answer "Yes" to "Compress entire disk now?" and have the process fully complete. No hitches.
+
+This makes me vaguely recall/wonder that perhaps this could be somehow related to LBA and/or Int 13h, or something floating around near that bunch of functionality. (I'm woefully ignorant about such low-level details.) Perhaps DOS/Win3.1 are stuck using a disk mode that QEMU has a buggy implementation of, while NT 4 (once NTOSKRNL is up and running) is able to use a different disk mode or access mechanism.
+
+I'm really interested to get some understanding of what the root issue is here, when this is fixed. (I wonder if it's a timing thing?)
+
+I've observed some unusual behavior with repeated restarts. In one case, I attempted to start NT4 multiple times, and QEMU consistently failed with "No bootable device" each time. So, I removed `-M isapc`, promptly got a boot menu, hit ^C, readded `-M isapc` - and continued to get a boot menu. Yep. I'll accept "really really big coincidence" but I do very much wonder if something else is going on here. I've observed many similar incidents. It makes me wonder whether the contents of memory or some other system state is an influence. Very probably not, but still...
+
+
+
+-- Reproduction --------------------------------------------
+
+First of all, there was unfortunately no way for me to avoid having to post entire disk images, but I've managed to compress everything down to 174MB total download size.
+
+FWIW, WinWorld and many other sites seem to have no operational issues providing clear pointers to CD keys; I consider my distribution of my installed HDD images an extension of the apparent status quo.
+
+That being said, I've put everything on Google Drive so nobody has to headscratch about Launchpad/Canonical/etc's stance on hosting this data.
+
+So, this folder contains the disk images: https://drive.google.com/drive/folders/1WdZVBh5Trs9HLC186-nHyKeqaSxfyM2c ("Download all" at the top-right will create a ZIP file, but FWIW downloading the individual files simultaneously would implement a rough form of download acceleration)
+
+File meta info:
+
+Compressed
+|
+|      Apparent
+|      |    Actual
+|      |    |
+38M -> 200M (103M)  win31.img.xz
+82M -> 1G   (289M)  wnt4ts-broken.img.xz
+55M -> 350M (146M)  wnt4ts-intermittent.img.xz
+
+SHA-256s:
+
+win31:        8179b8180a2ab40bd472e8a2f3fb89fc331651e56923f94ceb9e52a78ee220d2
+broken:       a2af5f0bc49a063b75f534b6ffe5b82e32ecc706a64a425b6626feccf6e3fdfa  
+intermittent: 77ae8c458829ebcdd64c71042012f45d5a2788e6ebd22db9d53de9ef1a574784
+
+(Wanted to keep the checksum lines within 80 columns)
+
+And, since I can't figure out where else in this report to put this, wnt4ts-broken.img's password is "admin" but something seems to have happened to the disk and NT doesn't actually boot properly :(, and wnt4ts-intermittent.img's password is "1234". (These were set up as test images. Now I'm _really_ glad I used simple passwords! :) )
+
+---
+
+
+I have two testcases: DOS 6.22 (+ Windows 3.1), and Windows NT 4.
+
+
+# MS-DOS
+
+DOS is the simplest. It basically consists of
+
+$ qemu-system-i386 -drive file=win31.img,format=raw -M isapc -enable-kvm
+
+And then literally just playing around. Things to try include creating files (`echo blah > file`), repeatedly seeking across the entire FAT (`dir /s > nul` or `dir /s`), and launching Windows (`win`).
+
+win31.img is not special (as far as I can tell) and merely consists of the result of installing DOS 6.22 and Windows 3.1 from WinWorldPC. I've basically just included the image for convenience.
+
+Generally no single "run" is immune to starting Win3.1 and then launching File Manager; if that doesn't generate an error, something is definitely up.
+
+The second best trigger is creating new files. That very very frequently produces "General Failure ...", but not always.
+
+
+# WinNT 4
+
+Windows NT 4 is a bit more complicated. Because this error only occurs at presumably a single small point very early in boot, the window of opportunity for the glitch to surface within is much much narrower and thus often requires a larger number of tries.
+
+Anecdotally I've had QEMU hit the boot error at the first try/run, and after as many as 63 "successful" boots.
+
+I made a small test harness that automates the launch process. It consists of two shell scripts and requires tmux (and netcat). (*Potential epilepsy warning*: if you use a light-colored terminal background, the terminal QEMU is repeatedly invoked from will continuously flash rapidly from white to black.)
+
+One of the scripts is run inside a tmux session in one terminal, while the other script is run in its own terminal (without any tmux).
+
+
+I named this one `run-qemu-loop`:
+
+--8<--------------------------------------------------------
+
+#!/bin/bash
+
+# ---
+
+qemu=/path/to/qemu-system-i386
+#or, alternatively: (I used the following line myself so I
+#could tab-complete my way to different qemu executables)
+#qemu="$1"
+
+disk=/path/to/wnt4ts-intermittent.img
+
+# ---
+
+port=4444
+
+rm -f STOP itercount
+
+itercount=0
+
+while :; do
+	
+	[ -f STOP ] && break
+	
+	((itercount++))
+	echo $itercount > itercount
+	
+	$qemu \
+		-enable-kvm -vga cirrus -curses -M isapc \
+		-drive file="$disk",format=raw \
+		-chardev socket,id=mon0,host=localhost,port=$port,server,nowait \
+		-mon chardev=mon0,mode=readline
+	
+	#point to an otherwise-unused terminal if you like (see also: `tty`)
+	#echo "$itercount run(s)" > /dev/pts/__
+	
+done
+
+------------------------------------------------------------
+
+Not much logic above; this just repeatedly runs QEMU for as long as
+the file `STOP` does not exist in the current directory.
+
+The key "magic" bit is that QEMU is launched in -curses mode.
+
+The other key bit is that the above script is run inside tmux.
+
+
+Here's `tmux-ctl-loop`:
+
+--8<--------------------------------------------------------
+
+#!/bin/bash
+
+port=4444
+
+tmux=./tmux
+
+printf -v l '%0.0s-' {0..25}
+h1="$l/ buffer dump begin \\$l"
+h2="$l-\\ buffer dump end /-$l"
+
+while :; do
+	
+	while :; do
+		echo | nc localhost $port -q0 -w1 > /dev/null && break
+		echo 'Start qemu!'
+	done
+	
+	buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)"
+	
+	echo "$h1"
+	[[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )'
+	echo "$h2"
+	
+	if echo "$buffer" | grep -q 'A disk read error occurred.'; then
+		
+		s="<Crashed after $(< itercount) runs.>"
+		echo "$s"
+		echo "$s" >> stats
+		
+		touch STOP
+		
+		#echo q | nc localhost $port -q0 > /dev/null
+		
+		exit
+		
+	elif echo "$buffer" | grep -q 'OS Loader V4.00'; then
+			
+		echo '<Booted successfully, trying again>'
+		
+		echo q | nc localhost $port -q0 > /dev/null
+		
+	else
+		
+		echo '<Waiting for boot>'
+		
+	fi
+			
+done
+
+------------------------------------------------------------
+
+Nothing particularly amazing going on here either.
+
+While `qemu-run-loop` is running inside tmux in the first terminal, this is running in the 2nd one.
+
+The small infinite loop at the top only breaks when it can successfully ping QEMU and it knows it's running.
+
+Then, a screendump of the contents of the terminal QEMU is in is fetched from tmux, and the buffer's content is analyzed.
+
+- If NTLDR fails, the script creates `STOP` to halt qemu-run-loop,
+  sends `q` to QEMU through netcat, and then the script exits.
+
+- If NTLDR loads successfully, the script sends `q` to QEMU and continues
+  looping. (qemu-run-loop will not find the `STOP` file, and so restart qemu.)
+
+The scripts run very quickly, with 2-3 iterations per second on my i3 box.
+
+
+
+# Usage
+
+Save the two scripts above to the same directory as wnt4ts-intermittent.img,
+then:
+
+- (If port 4444 doesn't work, the value needs to be changed in both scripts.)
+
+- In the first terminal, run `tmux -S <file>`, where <file> names the socket
+  tmux will use. This needs to match "tmux=" at the top of `tmux-ctl-loop`.
+  (with `tmux=./tmux`, the command would be `tmux -S tmux`)
+
+- Still in the first terminal (and now also inside tmux), enter
+  `./qemu-run-loop`, passing the path to qemu if you're using that approach
+  (refer to the first few lines of the script). Don't hit enter yet.
+
+- Now, in the 2nd terminal, type `./tmux-ctl-loop`
+
+- Hit enter in both terminals.
+ 
+
+Rationale for timing of Enter key:
+
+- Running qemu-run-loop first will start QEMU, and if NTLDR starts
+  successfully it will immediately begin counting down from 30. If NT actually
+  starts to boot and is then hard-shut-down this /may/ affect the disk image
+
+- tmux-ctl-loop will annoyingly spam a continuous stream of 'Start qemu!' until
+  qemu-run-loop is running.
+
+- Starting both scripts at "more or less" the same time (no rush) works out
+  well.
+
+
+Hopefully potential script modifications are obvious; for example
+
+- changing tmux-ctl-loop to not send 'q' to qemu so you can connect to the HMP
+  yourself
+  (NB, if `STOP` is not created, when qemu finally exits it will of course
+  promptly be relaunched)
+
+- pointing run-qemu-loop to a modified qemu binary
+
+
+
+== #2: QEMU-vs-VirtualBox image issue ======================
+
+I was initially completely stumped by this issue, perhaps unsurprisingly so. :)
+
+wnt4ts-broken.img is a perfectly ordinary NT 4 installation that was created in QEMU 2.9.0. I created a 1GB disk with `truncate`, picked NTFS and installed everything (which took a while).
+
+NT setup reboots a number of times during the boot process, and IIRC those all went just fine. However, at some point, the image began to consistently bomb out with "A disk read error occurred. ...", and stubbornly refused to boot, regardless of the number of boot attempts I tried.
+
+QEMU 2.0.0, 1.5.0, and 1.0 (the earliest version I was able to build on my system) all consistently hit "disk read error occurred".
+
+I tried compiling QEMU 1.0 using clang so I could build for 32-bit on my 64-bit system (GCC 7 died with "Frame pointer required, but reserved"). The resulting qemu completely crashed if I didn't enable KVM (ie, TCG was (understandably) broken); with KVM enabled qemu didn't crash, but NTLDR halted with the same error as on 64-bit qemu. (TL;DR, no difference whatsoever.)
+
+My initial reaction at this point was to try the image on another virtualization platform. My first pick was VirtualBox.
+
+So, I followed the official instructions for pointing VirtualBox to physical disk images, except I substituted a /dev/loopN device I'd pointed to the image file via losetup.
+
+And... VirtualBox picked the image up fine and Just Worked(TM). Yay! - but not yay. What gives?!
+
+Confused, I then tried to convert the disk image to VHD format. Unfortunately, for some reason, if I try `qemu-image convert ... -O vhdx ...`, VirtualBox chokes on the result:
+
+-----
+
+VD: error VERR_NOT_SUPPORTED opening image file
+'/.../wnt4ts-broken-qemuconv.vhd' (VERR_NOT_SUPPORTED).
+
+Result Code: NS_ERROR_FAILURE (0x80004005)
+Component: MediumWrap
+Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}
+Callee: IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945}
+Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
+
+-----
+
+Welp.
+
+Well, a bit more digging later, and I found I could do
+
+$ VBoxManage convertfromraw wnt4ts-broken.img wnt4ts-broken.vhd
+
+but... as soon as I pointed VirtualBox to this, it too began to choke with "A disk read error occurred".
+
+And yet, the VMDK->raw image setup worked just fine.
+
+I found I could even replace the loop device with the path of the .img file itself and that worked just fine too.
+
+At my wits' end, I followed some online instructions to learn about manual CHS configuration so I could try and get the image working in Bochs. "A disk read error occurred". I wasn't surprised.
+
+It was at this point I began to give up, but I decided to try One Last Thing(TM) before properly throwing in the towel.
+
+:)
+
+I decided to learn a bit more about how `VBoxManage internalcommands createrawvmdk` worked, and try one thing in particular: I can edit the .vmdk file, but can I point `createrawvmdk` at the .img file directly too?
+
+Turns out, yes you can.
+
+It also turns out that this promptly caused VirtualBox to bomb out.
+
+Interesting.
+
+For reference, here's the VMDK file I initially created (by pointing `createrawvmdk` at /dev/loopN) and then later edited to point straight to the .img file, with both approaches resulting in successful boot.
+
+--8<--------------------------------------------------------
+
+# Disk DescriptorFile
+version=1
+CID=e35b9a45
+parentCID=ffffffff
+createType="fullDevice"
+
+# Extent description
+RW 1536000 FLAT "/absolute/full/path/to/wnt4ts-broken.img" 0
+
+# The disk Data Base 
+#DDB
+
+ddb.virtualHWVersion = "4"
+ddb.adapterType="ide"
+ddb.geometry.cylinders="1523"
+ddb.geometry.heads="16"
+ddb.geometry.sectors="63"
+ddb.uuid.image="871a6044-c8ca-48ed-b7aa-e6fc49da3db4"
+ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
+ddb.uuid.modification="3661715c-3906-4e4a-ab65-486d140e03b8"
+ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"
+ddb.geometry.biosCylinders="761"
+ddb.geometry.biosHeads="32"
+ddb.geometry.biosSectors="63"
+
+------------------------------------------------------------
+
+
+Here's the _diff_ of what happens if I point `createrawvmdk` at wnt4ts-broken.img directly:
+
+--8<--------------------------------------------------------
+
+ddb.geometry.cylinders="2080"
+ddb.geometry.heads="16"
+ddb.geometry.sectors="63"
+
+------------------------------------------------------------
+
+:D
+
+Naturally,
+
+$ qemu-system-i386 -drive file=wnt4ts-broken.img,format=raw,cyls=1523,heads=16,secs=63 -M isapc -sdl
+
+will boot happily on 2.9.0 (notwithstanding the occasional "disk read error occurred" documented above).
+
+It will also boot in 1.6.0.
+
+(POTENTIAL BUG HEADSUP: 1.0 and 1.5.0 both lock up with a blank 640x480 window and use 0% CPU if I specify `-M isapc`.)
+
+And, of course, using these CHS values in Bochs also results in successful boot as well (after setting the CPU type to pentium).
+
+Unfortunately, I have no idea what sequence of events caused the creation of the VMDK file above. No invocation of `createrawvmdk` is producing a VMDK file with the CHS settings above.
+
+I've only just begun to learn about the intricacies of CHS. Am I to understand that these values are stored amongst the first 512 bytes of the disk? If this is the case, then I wonder what changed the data, and why. I was initially only using QEMU 2.9.0, and didn't move the image to different VMs or QEMU versions. Perhaps Windows NT got confused about the disk CHS and rewrote it?
+
+
+== Sporadic BIOS-level boot failure ========================
+
+I have multiple screenshots of SeaBIOS in QEMU 2.9.0 halting with "No bootable device" (et al), even with the above manually-applied CHS settings.
+
+Commit e689f7c also presents such errors.
+
+Commit 306ec6c does not suffer from intermittent breakage of any kind:
+
+- No SeaBIOS flake-outs
+- No "Non-system disk or disk error"
+- No "A disk error has occurred"
+- No "General failure ..."
+
+While most of my confidence in commit 306ec6c is based on anecdotal evidence, I modified `tmux-ctl-loop` a little to soak-test BIOS-level I/O stability and left this modified version running for a few minutes.
+
+--8<--------------------------------------------------------
+
+#!/bin/bash
+
+port=4444
+
+tmux=./tmux
+
+printf -v l '%0.0s-' {0..25}
+h1="$l/ buffer dump begin \\$l"
+h2="$l-\\ buffer dump end /-$l"
+
+while :; do
+	
+	while :; do
+		echo | nc localhost $port -q0 -w1 > /dev/null && break
+		echo 'Start qemu!'
+	done
+	
+	buffer="$(tmux -S $tmux capture-pane; tmux -S $tmux save-buffer -)"
+	
+	echo "$h1"
+	[[ "$buffer" ]] && echo "$buffer" || echo '( * Screen buffer is empty * )'
+	echo "$h2"
+	
+	if echo "$buffer" | grep -q 'Non-system disk' || echo "$buffer" | \
+		grep -q 'No bootable device'
+	then
+		
+		s="<Hit error after $(< itercount) runs.>"
+		echo "$s"
+		echo "$s" >> stats
+		
+		touch STOP
+		
+		#echo q | nc localhost $port -q0 > /dev/null
+		
+		exit
+		
+	elif echo "$buffer" | grep -q 'OS Loader V4.00' || echo "$buffer" | \
+		grep -q 'A disk read error'
+	then
+	
+		echo '<Boot did not hang at BIOS, trying again>'
+		
+		echo q | nc localhost $port -q0 > /dev/null
+		
+	else
+		
+		echo '<Waiting for boot>'
+		
+	fi
+			
+done
+
+------------------------------------------------------------
+
+For the above to work, the top of run-qemu-loop must also be modified to read something along the lines of
+
+disk=/path/to/wnt4ts-broken.img,format=raw,cyls=1523,heads=16,secs=63
+
+(Suggestion: modify copies of both scripts)
+
+One small terminal-flicker-headache (and a 57°C CPU) later, I was able to carefully observe just over 350 successful runs in which QEMU commit 306ec6c only ever produced a boot menu. No other hitches.
+
+** Important: ** 
+
+However, commit 306ec6c will fail to boot, ever, if the cylinders and geometry are not set to the values VirtualBox "discovered". (Of note is the fact that QEMU (2.9.0) was what initially created this image. I must admit that I don't remember what sequence of QEMU versions I fed the image to - and I maybe, possibly, didn't think to back the file up (sorry), so maybe something mangled something somewhere. But VirtualBox figured it out nonetheless!)
+
+Furthermore, feeding /dev/loopN to any QEMU version will NOT result in correct CHS discovery (and successful boot).
+
+This is what leads me to conclude that I've discovered two separate issues.
+
+
+
+== Appendix: How to build the branches =====================
+
+It's very simple.
+
+First, `git clone https://github.com/qemu/qemu` somewhere if you don't already have a local copy. If you have an old git checkout that's from 2014 or later, you can use that old checkout instead. (If you want to test an old checkout you have, the commands below will either work perfectly or completely bomb out with no side effects.)
+
+A full checkout is a ~183MB download. Sorry.
+
+Next, create two new directories somewhere. Name them what you like, eg `qemu-working` and `qemu-broken`.
+
+Now, cd into the checkout directory, and run:
+
+$ git archive 306ec6c3cece7004429c79c1ac93d49919f1f1cc | tar xC /path/to/qemu-working/
+
+$ git archive e689f7c668cbd9d08f330e17c3dd3a059c9553d3 | tar xC /path/to/qemu-broken/
+
+The paths can be relative.
+
+Now, run this in both of the new directories:
+
+$ ./configure --python=python2.7 --disable-libssh2 --disable-seccomp --disable-usb-redir --disable-guest-agent --disable-libiscsi --disable-spice --disable-smartcard-nss --disable-vhost-net --disable-docs --disable-attr --disable-cap-ng --disable-vde --disable-user --disable-bluez --disable-vnc-ws --disable-xen --disable-brlapi --enable-debug --target-list=i386-softmmu --disable-fdt
+
+$ make -j64
+
+You can open two terminals and configure and build both simultaneously if you like.
+
+On my decent but very basic (2-core+HT) i3 box, -j64 actually works out - make doesn't actually launch too many gcc processes. You *will* see your system load spike to ~20 though :)
+(NB. Do. not. use. -j64. with. the. linux. kernel.)
+
+On my system, a single build with -j64 takes only about 35 seconds. C FTW. (Although this has increased to 1min20sec for more recent builds.)
+
+Most of the configure arguments remove functionality I'll never use (in this situation) and which will only slow down the build.
+
+Once QEMU is built, run qemu-system-i386 directly from where it has been built.
+
+$ /path/to/qemu-working/i386-softmmu/qemu-system-i386 ...
+$ /path/to/qemu-broken/i386-softmmu/qemu-system-i386 ...
+
+Again, the paths can be relative.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1747056 b/results/classifier/gemma3:12b/boot/1747056
new file mode 100644
index 000000000..55a830b37
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1747056
@@ -0,0 +1,26 @@
+
+FreeDOS / MS-Dos / Windows 3.11 cannot perform reboot with 'isapc' machine
+
+I was installing MS-Dos 6.22 + Windows 3.11 in preparation for running Microsoft Bob, and noticed that when they try to perform a reboot, they just get stuck. The console cursor stays flashing on/off, but the DOS prompt no longer responds to input.
+
+It is fairly easy to reproduce, even FreeDOS is impacted - download the FreeDOS bootable CDROM image, then
+
+$ qemu-img create demo.img 100MB
+
+$ qemu-system-x86_64 -machine isapc -cdrom ~/Downloads/FD12CD.iso  -hda demo.img  -monitor stdio
+
+Wait for the installer to startup, and then in the monitor console run
+
+  sendkey ctrl-alt-delete
+
+It will fail to reboot
+
+Testing shows this is a regression from QEMU 2.8.0 onwards, and git bisect further narrowed it down to a SEABIOS update
+
+commit 6e99f5741ff1b408ea76e6caf2bd4f76df4060e9 (HEAD, tag: pull-seabios-20161027-2, tag: pull-seabios-20161027-1, refs/bisect/bad)
+Author: Gerd Hoffmann <email address hidden>
+Date:   Thu Oct 27 16:42:28 2016 +0200
+
+    seabios: update to 1.10.0 release.
+
+Note that this seems particular to the "isapc" machine type - with the "pc" machine type, reboot still works
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1754597 b/results/classifier/gemma3:12b/boot/1754597
new file mode 100644
index 000000000..e06660a8c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1754597
@@ -0,0 +1,35 @@
+
+qemu-system-x86_64 broken on ubuntu 17.10
+
+I have run a virtual machine over the past three years without problems, but the update to Ubuntu 17.10 broke it: the machine falls into an infinite boot loop.
+
+$ qemu-system-x86_64 --version
+QEMU emulator version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.5)
+
+$ sudo qemu-system-x86_64 -enable-kvm -usb \
+    -chardev stdio,id=char0 \
+    -device usb-host,vendorid=0x056a,productid=0x00c6 \
+    -device usb-host,vendorid=0x04a9,productid=0x2220 \
+    -soundhw all \
+    -m 2048 -cpu core2duo -machine q35  \
+    -smp 2 \
+    -device usb-mouse  \
+    -vga std  \
+    -device isa-applesmc,osk="CONFIDENTIAL" \
+    -smbios type=2 \
+    -device ide-drive,bus=ide.0,drive=HDD \
+    -drive id=HDD,if=none,cache=none,file=hdd.img \
+    -device ide-drive,bus=ide.3,drive=ScrapHDD \
+    -drive id=ScrapHDD,if=none,cache=none,file=scrap.img \
+    -netdev tap,id=net0,ifname=tap0,script=no \
+    -device e1000,netdev=net0,id=nic0,mac=00:aa:00:60:00:01
+
+$ uname -a
+Linux behemoth 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
+
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 17.10
+Release:	17.10
+Codename:	artful
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1757323 b/results/classifier/gemma3:12b/boot/1757323
new file mode 100644
index 000000000..aa56f4424
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1757323
@@ -0,0 +1,85 @@
+
+blue screen running windows 10 install DVD on qemu
+
+i get a blue screen at the first screen of the windows 10 DVD setup (Win10_1709_English_x64.iso, available from MS).
+
+The DVD boots fine, and gets to the first dialog: http://codewithoutborders.com/posted/qemu1.png
+and then if i just wait a minute of so it blue screen's.
+either DRIVER IRQL NOT LESS OR EQUAL: http://codewithoutborders.com/posted/qemu2.png
+or KMODE EXCEPTION NOT HANDLED: http://codewithoutborders.com/posted/qemu3.png
+
+
+
+
+the qemu command-line is:
+
+/usr/bin/qemu-system-x87_64 \
+ -boot strict=on \
+ -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-generic/monitor.sock,server,nowait \
+ -chardev spicevmc,id=charchannel0,name=vdagent \
+ -cpu core2duo,+lahf_lm,+pdcm,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,kvm=off \
+ -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7 \
+ -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6 \
+ -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1 \
+ -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2 \
+ -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=1 \
+ -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 \
+ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 \
+ -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 \
+ -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 \
+ -drive file=/mnt/ISOs/Win10_1709_English_x64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on \
+ -global kvm-pit.lost_tick_policy=discard \
+ -global PIIX4_PM.disable_s3=1 \
+ -global PIIX4_PM.disable_s4=1 \
+ -m 4096 \
+ -machine pc-i440fx-xenial,accel=tcg,usb=off \
+ -mon chardev=charmonitor,id=monitor,mode=control \
+ -msg timestamp=on \
+ -name generic \
+ -nodefaults \
+ -no-hpet \
+ -no-shutdown \
+ -no-user-config \
+ -realtime mlock=off \
+ -rtc base=utc,driftfix=slew \
+ -S \
+ -smp 2,sockets=2,cores=1,threads=1 \
+ -spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \
+ -uuid 3902a801-42dd-4bf2-8f3a-cbc68f4f8564
+
+
+$ /usr/bin/qemu-system-x87_64 --version
+QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24), Copyright (c) 2003-2008 Fabrice Bellard
+
+$ uname -a
+Linux host 4.13.0-37-generic #42~16.04.1-Ubuntu SMP Wed Mar 7 16:03:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
+
+$ cat /proc/cpuinfo 
+processor	: 0
+vendor_id	: GenuineIntel
+cpu family	: 6
+model		: 15
+model name	: Intel(R) Core(TM)2 Quad CPU           @ 2.66GHz
+stepping	: 7
+microcode	: 0x66
+cpu MHz		: 2671.406
+cache size	: 4096 KB
+physical id	: 0
+siblings	: 4
+core id		: 0
+cpu cores	: 4
+apicid		: 0
+initial apicid	: 0
+fpu		: yes
+fpu_exception	: yes
+cpuid level	: 10
+wp		: yes
+flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti retpoline tpr_shadow dtherm
+bugs		: cpu_meltdown spectre_v1 spectre_v2
+bogomips	: 5342.81
+clflush size	: 64
+cache_alignment	: 64
+address sizes	: 36 bits physical, 48 bits virtual
+power management:
+
+... 3 more times
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1759 b/results/classifier/gemma3:12b/boot/1759
new file mode 100644
index 000000000..a511548e7
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1759
@@ -0,0 +1,11 @@
+
+qemu-system-i386 error during install windows 95/98
+Description of problem:
+Installation of the Windows starts but when Windows 95 is supposed to copy files it failes like: ![qemu803_win95](/uploads/40e94adda4cdf5c57fa751d5db04ef7b/qemu803_win95.png)
+Installation of Windows 98 failes like: ![qemu803_win98](/uploads/110ece638cd71f8ec41dd029379af807/qemu803_win98.png)
+Steps to reproduce:
+1. get boot floppy & install cd for windows 95
+2. create hard drive C image
+3. try to install Windows 95
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/1776486 b/results/classifier/gemma3:12b/boot/1776486
new file mode 100644
index 000000000..9859378ce
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1776486
@@ -0,0 +1,8 @@
+
+detect error when kernel and initrd images exceed ram size
+
+I was unable to figure out why my VM wasn't booting when I added a "-initrd" image.  I would launch qemu and get no output, and no error message, it would just spin.
+
+Turns out my initrd image was around 270 MB but I wasn't giving an explicit ram size to qemu.  I was told the default memory size was around 120 MB so this was definitely a problem.  I think that the qemu "pseudo-bootloader" should detect when the kernel image and initrd image sizes exceed the size of ram and print a nice error to the user, something like:
+
+Error: the total size of the given boot images (342M) exceeds the size allocated for memory (120M)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1778350 b/results/classifier/gemma3:12b/boot/1778350
new file mode 100644
index 000000000..1e5268c1d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1778350
@@ -0,0 +1,14 @@
+
+Android-x86 4.4-r5 won't boot on QEMU since v2.11.0-rc2
+
+Try to boot from the Android-x86 4.4-r5 ISO won't boot in QEMU after 2.11.0-rc2. The last known version it works is 2.11.0-rc1.
+It also works on the 2.10.x-line, even the 2.10.2 which was released after 2.11.0-rc2!
+
+How to reproduce:
+Download the ISO from
+http://www.android-x86.org/releases/releasenote-4-4-r5 or directly https://www.fosshub.com/Android-x86.html/android-x86-4.4-r5.iso
+
+Start QEMU with this command-line: qemu-system-x86_64 -cdrom android-x86-4.4-r5.iso -m 1024
+
+On 2.11.0-rc1 and 2.10.2 after selecting to boot from CD it shows the Android splash after a short while ...
+On 2.11.0-rc2 through the latest 2.12 line it goes to black screen shortly right after selecting to boot from CD
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1793635 b/results/classifier/gemma3:12b/boot/1793635
new file mode 100644
index 000000000..4f4782eb3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1793635
@@ -0,0 +1,7 @@
+
+Using pflash with u-boot,when CONFIG_SYS_FLASH_USE_BUFFER_WRITE were defined,envirment args won't be able to save correctly
+
+Generated a u-boot image with qemu_arm_defconfig,did some modification to qemu-arm.h.
+Before added "CONFIG_SYS_FLASH_USE_BUFFER_WRITE",call saveenv in u-boot command line can save the envirment but painful slow.
+
+after added it,seems the action took no time,but the data won't be saved correctly,reset the board to boot again(i'd waited a while to reset the board) ,the u-boot will tell you enviremnt checksum mismatch,using the default.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1794202 b/results/classifier/gemma3:12b/boot/1794202
new file mode 100644
index 000000000..53e6f8517
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1794202
@@ -0,0 +1,4 @@
+
+Trying to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer."
+
+When I try to install Mac OS X 10.5, it gives this error, "Mac OS X cannot be installed on your computer." Command ran in the command-line: "C:\Program Files\qemu\qemu-system-ppc" -L pc-bios -boot d -M mac99,via=pmu -m 512 -hda "C:\Users\*****\Downloads\macosx105\MacOSHDD.qcow2" -cdrom "C:\Users\*****\Downloads\macosx105\osx leopard install.iso" -netdev user,id=mynet0 -device sungem,netdev=mynet0
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1795369 b/results/classifier/gemma3:12b/boot/1795369
new file mode 100644
index 000000000..fd3132a98
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1795369
@@ -0,0 +1,36 @@
+
+Record/replay (icount rr) causes emulation hang or exit with error about missing events in log
+
+Test case description:
+
+Guest image is Linux, which just powers off after kernel boots (instead of proceeding to user-space /init or /sbin/init).
+Base cmdline:
+  qemu-system-x86_64 \
+    -nodefaults -nographic -machine pc,accel=tcg -m 2048 -cpu qemu64 \
+    -kernel bzImage -initrd rootfs -append 'nokaslr console=ttyS0 rdinit=/init_poweroff' \
+    -serial SERIAL_VALUE \
+    -rtc clock=vm,base=2000-01-01T00:00:00 \
+    -icount 1,sleep=off,rr=RR_VALUE,rrfile=icount_rr_capture.bin
+
+Test 1.
+When SERIAL_VALUE=none
+Running with RR_VALUE=record completes successfully.
+Running with RR_VALUE=replay doesn't completes. qemu process just eating ~100% cpu and memory usage doesn't grow after some moment. I don't see what happens because of problem no.2 (see below).
+
+Test 2.
+When SERIAL_VALUE=stdio
+Running with RR_VALUE=record completes successfully.
+Running with RR_VALUE=replay causes exit with error:
+"qemu-system-x86_64: Missing character write event in the replay log"
+
+Tests 3,4,5...
+SERIAL_VALUE=stdio. Playing with "-rtc" clock and base suboptions, "-icount" sleep suboptions produces non-repeatable results.
+In most cases running with RR_VALUE=record completes successfully (but may hang at very begining).
+Running with RR_VALUE=replay with combinations of removing "-rtc base=..." and "-icount sleep=..." goes better, but at different places of boot process it may either hang (as in test 1) or exit with error (as in test 2).
+When qemu "hangs", it may also happen differently: either it can be stopped by Ctrl-C, or have to be killed.
+
+
+Guest image uploaded here: https://drive.google.com/open?id=1SHG4HyBdcPutc5Au4pyhN8z9w52et51A
+
+QEMU built from master (commit 042938f46e1c477419d1931381fdadffaa49d45e) with:
+<SRC_ROOT>/configure --prefix=<INSTALL_ROOT> --target-list=x86_64-softmmu --enable-debug --disable-pie --enable-tcg --disable-tcg-interpreter --enable-virtfs --disable-docs --disable-guest-agent --disable-modules --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-curses --disable-vnc --disable-vnc-sasl --disable-vnc-jpeg --disable-vnc-png --disable-cocoa --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-curl --disable-fdt --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-cap-ng --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-opengl --disable-virglrenderer --disable-qom-cast-debug --disable-tools --disable-vxhs --disable-crypto-afalg --disable-capstone --disable-replication --disable-xfsctl --disable-seccomp --disable-pvrdma --disable-libpmem
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1797262 b/results/classifier/gemma3:12b/boot/1797262
new file mode 100644
index 000000000..a73f5523b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1797262
@@ -0,0 +1,21 @@
+
+qemu arm no longer able to boot RPI Kernels
+
+Since RPi Kernel 1.20170427, qemu is no longer able to emulate the Rasberry Pi, as the linux kernel is complaining about timing issues.
+
+Old kernel output - https://pastebin.com/wvkneNNF
+New kernel output - https://pastebin.com/QTwgCkV2
+
+Note that the actual error is caused by the kernel being unable to get the timing source for the mmc (Line 160), which causes an unable-to-mount-root panic.  There are other issues with the serial port returning an invalid speed, which displays a divide-by-zero error, which is PROBABLY a symptom of the same root cause.
+
+This is simple to replicate - The last working kernel is available here:
+
+https://github.com/raspberrypi/firmware/tree/1.20170405/boot
+
+Download kernel7 and the dtb, and try to boot with (for example)
+
+qemu-system-aarch64 -M raspi2 -kernel kernel7.img -dtb bcm2709-rpi-2-b.dtb -serial stdio -sd noobs.img -append "root=/dev/mmcblk0p2 init=/bin/bash"
+
+This works, and boots successfully.   
+
+However, if you replace the kernel7.img and dtb with ones taken from https://github.com/raspberrypi/firmware/tree/1.20170427/boot it will NOT boot because of various clock timing issues (as in the second paste)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1801 b/results/classifier/gemma3:12b/boot/1801
new file mode 100644
index 000000000..17b0657be
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1801
@@ -0,0 +1,52 @@
+
+qemu-system-arm: Linux doesn't boot with UEFI (hangs after printing `EFI stub: Exiting boot services... `.)
+Description of problem:
+Ubuntu 23.04 (armhf) doesn't boot with UEFI.
+It hangs after printing `EFI stub: Exiting boot services... `.
+Steps to reproduce:
+```console
+$ qemu-system-arm -machine virt -m 2048 -nographic -bios /usr/local/share/qemu/edk2-arm-code.fd -hda ubuntu-23.04-server-cloudimg-armhf.img -snapshot
+UEFI firmware (version edk2-stable202302-for-qemu built at 17:13:00 on Mar 15 2023)                                                                  
+Error: Image at 000BFD84000 start failed: Not Found                                                                                                  
+Error: Image at 000BFCEE000 start failed: Unsupported                                                                                                
+Error: Image at 000BFC85000 start failed: Not Found                                                                                                  
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+Tpm2GetCapabilityPcrs fail!                                                                                                                          
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0)                                                                           
+BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0)                                                                          
+EFI stub: Booting Linux Kernel...                                         
+EFI stub: Entering in SVC mode with MMU enabled                  
+EFI stub: Using DTB from configuration table                      
+EFI stub: Exiting boot services... 
+```
+Additional information:
+It still boots when vmlinuz and initrd are directly specified:
+```console
+$ qemu-system-arm -machine virt -m 2048 -nographic -bios /usr/local/share/qemu/edk2-arm-code.fd -hda ubuntu-23.04-server-cloudimg-armhf.img -snapshot -kernel ubuntu-23.04-server-cloudimg-armhf-vmlinuz-lpae -initrd ubuntu-23.04-server-cloudimg-armhf-initrd-generic-lpae -append "root=LABEL=cloudimg-rootfs ro"                                          
+UEFI firmware (version edk2-stable202302-for-qemu built at 17:13:00 on Mar 15 2023)                                                                  
+Error: Image at 000BFD84000 start failed: Not Found                                                                                                  
+Error: Image at 000BFCEE000 start failed: Unsupported                                                                                                
+Tpm2SubmitCommand - Tcg2 - Not Found                                                                                                                 
+Tpm2GetCapabilityPcrs fail!                                               
+Tpm2SubmitCommand - Tcg2 - Not Found                                      
+EFI stub: Booting Linux Kernel...                                                                                                                    
+EFI stub: Entering in SVC mode with MMU enabled                                                                                                      
+EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path                                                                                 
+EFI stub: Using DTB from configuration table                                                                                                         
+EFI stub: Exiting boot services...                                                                                                                   
+[    0.000000] Booting Linux on physical CPU 0x0                                                                                                     
+[    0.000000] Linux version 6.2.0-26-generic-lpae (buildd@bos02-arm64-018) (arm-linux-gnueabihf-gcc-12 (Ubuntu 12.2.0-17ubuntu1) 12.2.0, GNU ld (GNU
+ Binutils for Ubuntu) 2.40) #26-Ubuntu SMP Tue Jul 11 10:32:58 UTC 2023 (Ubuntu 6.2.0-26.26-generic-lpae 6.2.13)
+[    0.000000] CPU: ARMv7 Processor [414fc0f0] revision 0 (ARMv7), cr=30c5387d
+...
+Ubuntu 23.04 ubuntu ttyAMA0
+
+ubuntu login:
+```
+
+
+Files:
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/ubuntu-23.04-server-cloudimg-armhf.img
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/unpacked/ubuntu-23.04-server-cloudimg-armhf-vmlinuz-lpae
+- https://cloud-images.ubuntu.com/releases/23.04/release-20230729/unpacked/ubuntu-23.04-server-cloudimg-armhf-initrd-generic-lpae
diff --git a/results/classifier/gemma3:12b/boot/1801933 b/results/classifier/gemma3:12b/boot/1801933
new file mode 100644
index 000000000..9f6ccc976
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1801933
@@ -0,0 +1,25 @@
+
+default memory parameter too small on x86_64 today
+
+Launching a centos7 VM today does not work anymore on x86_64 without increasing the size of the memory parameter. For example with this command :
+
+$ /opt/qemu-3.0.0/bin/qemu-system-x86_64 --curses   -enable-kvm -drive file=file.dd,index=0,media=disk -drive file=centos-x86_64.iso,index=1,media=cdrom
+
+[    3.047614] Failed to execute /init
+[    3.048315] Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
+[    3.049258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-693.21.1.el7.x86
+
+
+
+Increasing the size from the default 128MiB to 512MiB let the VM works without problem.
+So, ok, it's not a qemu problem, it's more a "User problem" and interface problem for me.
+But it push me in the end to launch VirtualBox instead of qemu, because the default parameter does not work anymore... And I had no time to investigate why it does not work because the message is not visible.
+Debian iso with the same command line for example show a message to tell me that there is not enough memory, so it help me to track the real issue behind.
+
+But... In the end, I think today, the default memory parameter on x86_64 is too small and it can lead some people like me to switch to VirtualBox.
+VirtualBox, in the wizard is set by default to 4MiB Ram size, which tell you... Ok I need to put more. But, you know that 4MiB is not enough in the end.
+
+
+Regards,
+
+Johann
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1804961 b/results/classifier/gemma3:12b/boot/1804961
new file mode 100644
index 000000000..eb26fd4e6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1804961
@@ -0,0 +1,10 @@
+
+qemu-system-aarch64: Windows 10 ARM64 BSoD on boot while using virt-3.0
+
+When I emulate a virt-3.0 machine, Windows 10 BSoD on boot, with the error code being ACPI_BIOS_ERROR(0x000000A5), virt-2.12 boots fine.
+
+Windows Build: 10.0.17134.1
+QEMU version: 3.0.0
+Commandline: qemu-system-aarch64 -M virt -accel tcg,thread=multi -cpu cortex-a57 -smp 2 -m 2048 -bios QEMU_EFI.fd -device ramfb -device nec-usb-xhci -device usb-kbd -device usb-tablet -hda disk.vhd -vnc :0
+
+By the way, the patch to add DBG2 table discussed here https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg02550.html works (although minor change is required to adapt to the qemu 3.0.0 code), the table is accepted by Windows (Windows require both DBG2 and SPCR to be valid for serial kernel debugging to work), so it may help further diagnosing this issue.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1806 b/results/classifier/gemma3:12b/boot/1806
new file mode 100644
index 000000000..f7046b003
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1806
@@ -0,0 +1,6 @@
+
+Tests: YAMON binaries unavailable
+Description of problem:
+The [tests for MIPS](https://gitlab.com/qemu-project/qemu/-/blame/master/tests/avocado/machine_mips_malta.py#L127) download the YAMON firmware binaries, however that link does not exist anymore. It appears that it may have [moved to ](https://www.mips.com/develop/tools/boot-loaders/)mips.com (or maybe that's where it came from?), which states "To support existing users of these, and the QEMU project, YAMON is now available under the GPL License." However those links are also dead. I've not been able to find the referenced binaries or source anywhere. @philmd, do you happen to have a copy you can upload? Alternatively, I've found the 2.16 source [here](https://github.com/binsgit/mips-yamon).
+
+Another alternative would be to use U-boot, which is easy to get a hold of and would work for this test (just getting to a prompt, although I've had issues with it being able to access an IDE drive). I haven't found prebuilt binaries for MIPS and u-boot though.
diff --git a/results/classifier/gemma3:12b/boot/1810956 b/results/classifier/gemma3:12b/boot/1810956
new file mode 100644
index 000000000..5f952f240
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1810956
@@ -0,0 +1,9 @@
+
+qemu-2.12.1 crashes when running malicious bootloader.
+
+Running specific bootloader on Qemu causes fatal error and 
+hence SIGABRT in /qemu-2.12.1/tcg/tcg.c on line 2684.
+
+Bootloader binary code is included in attachments.
+The code was generated by assembling a valid bootloader, then
+appending random-bytes from file `/dev/urandom` to the binary file.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1811782 b/results/classifier/gemma3:12b/boot/1811782
new file mode 100644
index 000000000..046f54914
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1811782
@@ -0,0 +1,6 @@
+
+QEMU Windows fails to mount rootfs on an ISO where QEMU Linux works normally
+
+I have installed QEMU 3.1.0 for Microsoft Windows from https://qemu.weilnetz.de/w64/ . When I give the command "qemu-system-x86_64.exe -cdrom ..\QemuSaver\freeduc2.iso", qemu boots the ISO, but the resulting Linux kernel panics when trying to mount the root file system. Running the equivalent command under Linux (OpenSuSE Leap 15.0) results in success.
+I will attach a screenshot of the command and the kernel panic message.
+To reproduce the problem, download the zip file from Google Drive here https://drive.google.com/file/d/1bAozvGeRF7PbkOnJKzrFHxhUh2kDLz6L/view?usp=sharing, and unpack it under Microsoft Windows. You can either run the installer (which will install QEMU 3.0.0 and an ISO image in C:\QemuSaver) or you can run the command I gave from the directory where your QEMU is installed.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1811888 b/results/classifier/gemma3:12b/boot/1811888
new file mode 100644
index 000000000..efb9104da
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1811888
@@ -0,0 +1,14 @@
+
+Qemu refuses to multiboot Elf64 kernels
+
+Qemu does not multiboot Elf64 bit kernels when emulating x86_64 systems. This is unfortunate because it renders the `-kernel` option quite useless. It's true that a multiboot compatible bootloader puts you in protected mode by default, and you have to set up the long mode yourself. While it is easy to put such 32-bit bootstrap code in a 64 bit binary, it is not possible to compile a 64 bit kernel into a 32 bit binary.
+
+After quick search, it turned out that loading 64 bit elf binaries has been disabled to be compatible with GRUB. However, since that time, both GRUB and Syslinux load 64 bit ELF kernels just fine, which makes qemu incompatible with them. Furthermore, it seems that this feature does and has always worked fine and that people have since submitted patches to re-enable it.
+
+https://patchwork.ozlabs.org/patch/62142/
+https://patchwork.kernel.org/patch/9770523/
+
+Please consider applying the attached patch.
+
+Best Regards,
+Lukasz Janyst
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1814343 b/results/classifier/gemma3:12b/boot/1814343
new file mode 100644
index 000000000..16e8f1575
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1814343
@@ -0,0 +1,31 @@
+
+Initrd not loaded on riscv32
+
+I attempted to run qemu with a ram disk. However, when reading the contents of the disk from within the VM I only get back zeros.
+
+I was able to trace the issue to a mismatch of expectations on line 93 of hw/riscv/virt.c. Specifically, when running in 32-bit mode the value of kernel_entry is sign extended to 64-bits, but load_image_targphys expects the start address to not be sign extended.
+
+Straw man patch (works for 32-bit but would probably break 64-bit VMs?):
+
+diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
+index e7f0716fb6..32216f993c 100644
+--- a/hw/riscv/virt.c
++++ b/hw/riscv/virt.c
+@@ -90,7 +90,7 @@ static hwaddr load_initrd(const char *filename, uint64_t mem_size,
+      * halfway into RAM, and for boards with 256MB of RAM or more we put
+      * the initrd at 128MB.
+      */
+-    *start = kernel_entry + MIN(mem_size / 2, 128 * MiB);
++    *start = (kernel_entry & 0xffffffff) + MIN(mem_size / 2, 128 * MiB);
+ 
+     size = load_ramdisk(filename, *start, mem_size - *start);
+     if (size == -1) {
+
+
+Run command:
+
+$ qemu/build/riscv32-softmmu/qemu-system-riscv32 -machine virt -kernel mykernel.elf -nographic -initrd payload
+
+Commit hash:
+
+3a183e330dbd7dbcac3841737ac874979552cca2
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1818367 b/results/classifier/gemma3:12b/boot/1818367
new file mode 100644
index 000000000..a6c60436a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1818367
@@ -0,0 +1,150 @@
+
+Initialization of device cfi.pflash01 failed: Block node is read-only
+
+Hi,
+
+I have several vms defined in libvirt using ovmf for uefi, since a later
+update of my server I'm unable to start any of the domains defined. This is
+an example of the output given:
+
+# virsh start os-1
+error: Failed to start domain os-1
+error: internal error: qemu unexpectedly closed the monitor: 2019-03-02T21:23:51.726446Z qemu-system-x86_64: Initialization of device cfi.pflash01 failed: Block node is read-only
+
+an example of domain is like this:
+
+<domain type='kvm'>                                                                                                                                                                                                                                                            
+  <name>os-1</name>                                                                                                                                                                                                                                                            
+  <uuid>34c41008-ab91-483b-959c-81a7a12ae9be</uuid>                                                                                                                                                                                                                            
+  <memory unit='KiB'>8388608</memory>                                                                                                                                                                                                                                          
+  <currentMemory unit='KiB'>8388608</currentMemory>                                                                                                                                                                                                                            
+  <memoryBacking>                                                                                                                                                                                                                                                              
+    <hugepages/>                                                                                                                                                                                                                                                               
+  </memoryBacking>                                                                                                                                                                                                                                                             
+  <vcpu placement='static' cpuset='10-11,34-35'>4</vcpu>                                                                                                                                                                                                                       
+  <os>                                                                                                                                                                                                                                                                         
+    <type arch='x86_64' machine='pc-i440fx-2.12'>hvm</type>                                                                                                                                                                                                                    
+    <loader type='pflash'>/var/lib/libvirt/qemu/nvram/os-1-ovmf.fd</loader>                                                                                                                                                                                                    
+    <boot dev='network'/>                                                                                                                                                                                                                                                      
+    <boot dev='hd'/>                                                                                                                                                                                                                                                           
+  </os>                                                                                                                                                                                                                                                                        
+  <features>                                                                                                                                                                                                                                                                   
+    <acpi/>                                                                                                                                                                                                                                                                    
+    <apic/>                                                                                                                                                                                                                                                                    
+  </features>                                                                                                                                                                                                                                                                  
+  <cpu mode='host-passthrough' check='partial'/>                                                                                                                                                                                                                               
+  <clock offset='utc'>                                                                                                                                                                                                                                                         
+    <timer name='rtc' tickpolicy='catchup'/>                                                                                                                                                                                                                                   
+    <timer name='pit' tickpolicy='delay'/>                                                                                                                                                                                                                                     
+    <timer name='hpet' present='no'/>                                                                                                                                                                                                                                          
+  </clock>                                                                                                                                                                                                                                                                     
+  <on_poweroff>destroy</on_poweroff>                                                                                                                                                                                                                                           
+  <on_reboot>restart</on_reboot>                                                                                                                                                                                                                                               
+  <on_crash>destroy</on_crash>                                                                                                                                                                                                                                                 
+  <pm>                                                                                                                                                                                                                                                                         
+    <suspend-to-mem enabled='no'/>                                                                                                                                                                                                                                             
+    <suspend-to-disk enabled='no'/>                                                                                                                                                                                                                                            
+  </pm>                                                                                                                                                                                                                                                                        
+  <devices>                                                                                                                                                                                                                                                                    
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>                                                                                                                                                                                                                           
+    <disk type='block' device='disk'>                                                                                                                                                                                                                                          
+      <driver name='qemu' type='raw' cache='none' io='native'/>                                                                                                                                                                                                                
+      <source dev='/dev/vg0/os-1-vda'/>                                                                                                                                                                                                                                   
+      <target dev='vda' bus='virtio'/>                                                                                                                                                                                                                                         
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>                                                                                                                                                                                              
+    </disk>                                                                                                                                                                                                                                                                    
+    <disk type='block' device='disk'>
+      <driver name='qemu' type='raw' cache='none' io='native'/>
+      <source dev='/dev/vg0/os-1-vdb'/>
+      <target dev='vdb' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </disk>
+    <controller type='usb' index='0' model='ich9-ehci1'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci1'>
+      <master startport='0'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci2'>
+      <master startport='2'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
+    </controller>
+    <controller type='usb' index='0' model='ich9-uhci3'>
+      <master startport='4'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'/>
+    <controller type='ide' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <interface type='bridge'>
+      <mac address='52:54:00:78:cb:97'/>
+      <source bridge='virbr0'/>
+      <model type='rtl8139'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </interface>
+    <interface type='bridge'>
+      <mac address='52:54:00:1c:4f:22'/>
+      <source bridge='virbr1'/>
+      <model type='rtl8139'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+    </serial>
+    <console type='pty'>
+      <target type='serial' port='0'/>
+    </console>
+    <input type='mouse' bus='ps2'/>
+    <input type='keyboard' bus='ps2'/>
+    <graphics type='vnc' port='-1' autoport='yes'>
+      <listen type='address'/>
+    </graphics>
+    <video>
+      <model type='cirrus' vram='16384' heads='1' primary='yes'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <memballoon model='virtio'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
+    </memballoon>
+  </devices>
+</domain>
+
+where /var/lib/libvirt/qemu/nvram/os-1-ovmf.fd is a copy of
+/usr/share/edk2-ovmf/OVMF_VARS.fd. An the extract from my
+/etc/libvirt/qemu.conf to define ovmf:
+
+...
+# Location of master nvram file                                                                                                                                                                                                                                                
+#                                                                                                                                                                                                                                                                              
+# When a domain is configured to use UEFI instead of standard                                                                                                                                                                                                                  
+# BIOS it may use a separate storage for UEFI variables. If                                                                                                                                                                                                                    
+# that's the case libvirt creates the variable store per domain                                                                                                                                                                                                                
+# using this master file as image. Each UEFI firmware can,                                                                                                                                                                                                                     
+# however, have different variables store. Therefore the nvram is                                                                                                                                                                                                              
+# a list of strings when a single item is in form of:                                                                                                                                                                                                                          
+#   ${PATH_TO_UEFI_FW}:${PATH_TO_UEFI_VARS}.                                                                                                                                                                                                                                   
+# Later, when libvirt creates per domain variable store, this list is                                                                                                                                                                                                          
+# searched for the master image. The UEFI firmware can be called                                                                                                                                                                                                               
+# differently for different guest architectures. For instance, it's OVMF                                                                                                                                                                                                       
+# for x86_64 and i686, but it's AAVMF for aarch64. The libvirt default                                                                                                                                                                                                         
+# follows this scheme.                                                                                                                                                                                                                                                         
+nvram = [                                                                                                                                                                                                                                                                      
+   "/usr/share/edk2-ovmf/OVMF_CODE.fd:/usr/share/edk2-ovmf/OVMF_VARS.fd",                                                                                                                                                                                                      
+]
+...
+
+This setup used to work one month ago, now it's setup with:
+
+QEMU emulator version 3.1.0
+libvirt-5.0.0
+linux-4.19.20
+
+Any help appreciated.
+
+Best regards.
+
+José
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1819289 b/results/classifier/gemma3:12b/boot/1819289
new file mode 100644
index 000000000..43909d2be
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1819289
@@ -0,0 +1,4 @@
+
+Windows 95 and Windows 98 will not install or run
+
+The last version of QEMU I have been able to run Windows 95 or Windows 98 on was 2.7 or 2.8. Recent versions since then even up to 3.1 will either not install or will not run 95 or 98 at all. I have tried every combination of options like isapc or no isapc, cpu pentium  or cpu as 486. Tried different memory configurations, but they just don't work anymore.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1822012 b/results/classifier/gemma3:12b/boot/1822012
new file mode 100644
index 000000000..76bbd3475
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1822012
@@ -0,0 +1,12 @@
+
+powernv machine complains of missing skiboot files
+
+Hi, I want to use the powernv machine from the qemu-system-ppcle application. However, when I specify this machine, qemu complains that it can't find the skiboot files.
+
+I noticed that skiboot is available for Ubuntu, but only for the PPC[64] hosts. Well, I just need skiboot files for qemu on amd64 hosts.
+
+Hmm, looks like Debian has a package for these missing qemu files:
+
+https://packages.debian.org/sid/qemu-skiboot
+
+Could we promote these to Ubuntu repositories, and fix the qemu packages so that they automatically depend on the necessary BIOS packages? For example, openbios-ppc should also be installed when qemu-system-ppc[64[le]] are installed.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1823152 b/results/classifier/gemma3:12b/boot/1823152
new file mode 100644
index 000000000..3acae5857
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1823152
@@ -0,0 +1,37 @@
+
+QEMU not able to boot ubuntu 18.04 as a guest
+
+Host information:
+sushant@sushant-OptiPlex-7050:~$ lsb_release -a
+No LSB modules are available.
+Distributor ID:	Ubuntu
+Description:	Ubuntu 18.04.2 LTS
+Release:	18.04
+Codename:	bionic
+
+
+QEMU version:
+sushant@sushant-OptiPlex-7050:~$ /usr/bin/qemu-system-x86_64   --version
+QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.12)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+
+
+I am trying to install xubuntu 18.04 as a qemu guest. The installation process goes smoothly and I reboot. After reboot, the boot process hangs with black screen and a blinking pointer. I used the following steps to install and boot the machine:
+sudo qemu-img create /var/lib/libvirt/images/xubuntu18_04.qcow2 30G
+
+sudo qemu-system-x86_64-spice -enable-kvm -cpu host -boot d -cdrom /home/sushant/Downloads/xubuntu-18.04.2-desktop-amd64.iso /var/lib/libvirt/images/xubuntu18_04.qcow2   -m 8G
+
+sudo qemu-system-x86_64-spice -enable-kvm -cpu host  /var/lib/libvirt/images/xubuntu18_04.qcow2   -m 8G
+
+
+
+
+
+
+I tried with ubuntu 18.04(deafult ubuntu) and it also hangs with error "removed slice user slice of gdm"
+
+
+Also, if I install ubuntu 16.04 as guest, it boots smoothly.
+
+What should be done?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1823998 b/results/classifier/gemma3:12b/boot/1823998
new file mode 100644
index 000000000..d3876d114
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1823998
@@ -0,0 +1,12 @@
+
+qemu-system-aarch64: support kernels bigger than 128MiB
+
+Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd.
+
+This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size of the kernel Image and unpopulated BSS, the dtb (or kernel) will be clobbered by the other, resulting in a silent boot failure.
+
+Since v3.17, the kernel Image header exposes a field called image_size, which describes the entire size of the kernel (including unpopulated sections such as the BSS) as a 64-bit little-endian value. For kernels prior to v3.17, this field is zero. This is documented at:
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt?h=v5.0#n68
+
+It would be great if QEMU could take the image_size field into account when placing the initrd and dtb to avoid overlap with the kernel.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1825207 b/results/classifier/gemma3:12b/boot/1825207
new file mode 100644
index 000000000..2e54b96c2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1825207
@@ -0,0 +1,26 @@
+
+fw_cfg_machine_reset destroys user bootorder setting
+
+Demonstrated against 2.11 (ubuntu bionic 1:2.11+dfsg-1ubuntu7.12) and 3.1 (as built under bionic from the 1:3.1+dfsg-2ubuntu3 source package) although the code hasn't changed between them and github master also appears to have this same code branch.
+
+What I was trying to do: select a boot disk using `-fw_cfg name=bootorder,string=/pci@i0cf8/*@6` based on the qemu and seabios documentation.  (Why do I want to do that? using qemu for installer testing for a specific kind of real machine and need to match the bios boot order.)
+
+What happened instead: same search-based boot order that I get without that option.  Also, /sys/firmware/qemu_fw_cfg/by_name/bootorder/raw is empty and .../size is "0".
+
+Brutal work around that did a useful thing: 
+
+--- qemu-3.1+dfsg.orig/hw/nvram/fw_cfg.c
++++ qemu-3.1+dfsg/hw/nvram/fw_cfg.c
+@@ -869,8 +869,10 @@ static void fw_cfg_machine_reset(void *o
+     FWCfgState *s = opaque;
+     char *bootindex = get_boot_devices_list(&len);
+ 
++#if 0
+     ptr = fw_cfg_modify_file(s, "bootorder", (uint8_t *)bootindex, len);
+     g_free(ptr);
++#endif
+ }
+
+This change allowed the boot to work (so my bootorder setting was making it to seabios) and also showed up explicitly in /sys/firmware/qemu_fw_cfg.
+
+I don't know if fw_cfg_modify_file is intended to append rather than replace, but it doesn't; based on the seabios "Runtime_config" docs which suggest "look at the Searching bootorder for output and paste that into the bootorder file" I'd instead just have it only fill in bootorder if there's *no* existing setting, since a user can read out the defaults and copy them in as described if they want the fallback, but that's just from my interpretation of the docs.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1827871 b/results/classifier/gemma3:12b/boot/1827871
new file mode 100644
index 000000000..da1e22b2b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1827871
@@ -0,0 +1,44 @@
+
+Race condition when rebooting with the TCG backend
+
+Reporting this as present in QEMU 3.1.0, although I don't see any commit in current git master (a6ae23831b05a11880b40f7d58e332c45a6b04f7) that would suggest this issue is fixed.
+
+    $ uname -a
+    Linux boole 4.19.0-4-686-pae #1 SMP Debian 4.19.28-2 (2019-03-15) i686 GNU/Linux
+    $ qemu -version
+    QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-7)
+    Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
+
+Here's an excerpt from the code which handles reboot requests in SeaBIOS 1.12, located in src/fw/shadow.c:
+
+    // Request a QEMU system reset.  Do the reset in this function as
+    // the BIOS code was overwritten above and not all BIOS
+    // functionality may be available.
+
+    // Attempt PCI style reset
+    outb(0x02, PORT_PCI_REBOOT);
+    outb(0x06, PORT_PCI_REBOOT);
+
+    // Next try triple faulting the CPU to force a reset
+    asm volatile("int3");
+
+This compiles to the following:
+
+    (qemu) x/10i 0xf1993
+    0x000f1993:  b0 02                    movb     $2, %al
+    0x000f1995:  ee                       outb     %al, %dx
+    0x000f1996:  b0 06                    movb     $6, %al
+    0x000f1998:  ee                       outb     %al, %dx
+    0x000f1999:  cc                       int3     
+    0x000f199a:  80 3d 0d 53 0f 00 08     cmpb     $8, 0xf530d
+    0x000f19a1:  75 52                    jne      0xf19f5
+    0x000f19a3:  a1 10 53 0f 00           movl     0xf5310, %eax
+    0x000f19a8:  8b 15 14 53 0f 00        movl     0xf5314, %edx
+    0x000f19ae:  89 c3                    movl     %eax, %ebx
+
+Now, with the TCG backend, upon reaching the second outb instruction, the thread executing JIT-ed opcodes invokes qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET). This signals another thread to reset the guest CPU registers to their initial state. However, the execution thread is *not* stopped, which means it will keep executing already-translated instructions in the TCG buffer. In particular, the bootstrap value of the EIP register will be overwritten. On my machine, this usually results in the guest CPU finding itself in real mode, CS base 0xffff0000, EIP 0x0000199e, which in real mode disassembles to this:
+
+    (qemu) xp/1i 0xf199e
+    0x000f199e:  0f 00 08                 strw     0(%bx, %si)
+
+This instruction triggers a #UD exception, and given that SeaBIOS handles #UD by immediately returning, it manifests as the guest locking up with 100% CPU usage every other reboot.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1829576 b/results/classifier/gemma3:12b/boot/1829576
new file mode 100644
index 000000000..1c7ec73f3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1829576
@@ -0,0 +1,54 @@
+
+QEMU-SYSTEM-PPC64 Regression QEMU-4.0.0
+
+I have been using QEMU-SYSTEM-PPC64 v3.1.0 to run CentOS7 PPC emulated system. It stopped working when I upgraded to QEMU-4.0.0 . I downgraded back to QEMU-3.1.0 and it started working again. The problem is that my CentOS7 image will not boot up udner QEMU-4.0.0, but works fine under QEMU-3.1.0.
+
+I have an QCOW2 image available at https://www.mediafire.com/file/d8dda05ro85whn1/linux-centos7-ppc64.qcow2/file . NOTE: It is 15GB. Kind of large.
+
+I run it as follows:
+
+   qemu-system-ppc64 \
+      -name "CENTOS7-PPC64" \
+      -cpu POWER7 -machine pseries \
+      -m 4096 \
+      -netdev bridge,id=netbr0,br=br0 \
+      -device e1000,netdev=netbr0,mac=52:54:3c:13:21:33 \
+      -hda "./linux-centos7-ppc64.qcow2" \
+      -monitor stdio
+
+HOST: I am using Manjaro Linux on an Intel i7 machine with the QEMU packages installed via the package manager of the distribution.
+
+[jsantiago@jlsws0 ~]$ uname -a
+Linux jlsws0.haivision.com 4.19.42-1-MANJARO #1 SMP PREEMPT Fri May 10 20:52:43 UTC 2019 x86_64 GNU/Linux
+
+jsantiago@jlsws0 ~]$ cpuinfo 
+Intel(R) processor family information utility, Version 2019 Update 3 Build 20190214 (id: b645a4a54)
+Copyright (C) 2005-2019 Intel Corporation.  All rights reserved.
+
+=====  Processor composition  =====
+Processor name    : Intel(R) Core(TM) i7-6700K  
+Packages(sockets) : 1
+Cores             : 4
+Processors(CPUs)  : 8
+Cores per package : 4
+Threads per core  : 2
+
+=====  Processor identification  =====
+Processor	Thread Id.	Core Id.	Package Id.
+0       	0   		0   		0   
+1       	0   		1   		0   
+2       	0   		2   		0   
+3       	0   		3   		0   
+4       	1   		0   		0   
+5       	1   		1   		0   
+6       	1   		2   		0   
+7       	1   		3   		0   
+=====  Placement on packages  =====
+Package Id.	Core Id.	Processors
+0   		0,1,2,3		(0,4)(1,5)(2,6)(3,7)
+
+=====  Cache sharing  =====
+Cache	Size		Processors
+L1	32  KB		(0,4)(1,5)(2,6)(3,7)
+L2	256 KB		(0,4)(1,5)(2,6)(3,7)
+L3	8   MB		(0,1,2,3,4,5,6,7)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1829682 b/results/classifier/gemma3:12b/boot/1829682
new file mode 100644
index 000000000..588bcc8d0
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1829682
@@ -0,0 +1,154 @@
+
+QEMU PPC SYSTEM regression - 3.1.0 and GIT - Fail to boot AIX
+
+Built from source on a debian system
+
+Linux db08 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
+gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
+
+Last git commit (from queued gdibson repository)
+
+starting AIX 7.2 TL 2 SP 2 with the following : (the install was done under qemu 3.1.0)
+
+qemu-system-ppc64 -M pseries \
+    -cpu power7 \
+    -cdrom AIX_v7.2_Install_7200-02-02-1806_DVD_1_of_2_32018.iso \
+    -net nic \
+    -net tap,ifname=tap2,script=no \
+    -drive file=DISK1.IMG,if=none,id=drive-virtio-disk0 \
+    -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=drive-virtio-disk0 \
+    -m 4G \
+    -serial stdio \
+    -monitor unix:ms,server,nowait \
+    -accel tcg \
+    -k fr \
+    -nographic \
+    -prom-env input-device=/vdevice/vty@71000000 \
+    -prom-env output-device=/vdevice/vty@71000000 \
+    -prom-env diag-switch?=false \
+    -prom-env boot-command="boot /pci@800000020000000/scsi@2/disk@100000000000000 -s verbose"
+
+Yields this :
+
+
+^M
+SLOF^[[0m^[[?25l **********************************************************************^M
+^[[1mQEMU Starting^M
+^[[0m Build Date = Jan 14 2019 18:00:39^M
+ FW Version = git-a5b428e1c1eae703^M
+ Press "s" to enter Open Firmware.^M^M
+^M^M
+^[[0m^[[?25hC0000^MC0100^MC0120^MC0140^MC0200^MC0240^MC0260^MC02E0^MC0300^MC0320^MC0340^MC0360^MC0370^MC0380^MC0371^MC0372^MC0373^MC0374^MC03F0^MC0400^MC0480^MC04C0^MC04D0^MC0500^MPopulating /vdevice methods^M
+Populating /vdevice/vty@71000000^M
+Populating /vdevice/nvram@71000001^M
+Populating /vdevice/l-lan@71000002^M
+Populating /vdevice/v-scsi@71000003^M
+       SCSI: Looking for devices^M
+          8200000000000000 CD-ROM   : "QEMU     QEMU CD-ROM      2.5+"^M
+C05A0^MPopulating /pci@800000020000000^M
+                     00 0000 (D) : 1234 1111    qemu vga^M
+                     00 0800 (D) : 1033 0194    serial bus [ usb-xhci ]^M
+                     00 1000 (D) : 1af4 1004    virtio [ scsi ]^M
+Populating /pci@800000020000000/scsi@2^M
+       SCSI: Looking for devices^M
+          100000000000000 DISK     : "QEMU     QEMU HARDDISK    2.5+"^M
+C0600^MC06C0^MC0700^MC0800^MC0880^MC0890^MC08A0^MC08A8^MInstalling QEMU fb^M
+^M
+^M
+^M
+C08B0^MScanning USB ^M
+  XHCI: Initializing^M
+    USB Keyboard ^M
+    USB mouse ^M
+C08C0^MC08D0^MNo console specified using screen & keyboard^M
+User selected input-device console: /vdevice/vty@71000000^M
+User selected output-device console: /vdevice/vty@71000000^M
+C08E0^MC08E8^MC08FF^M     ^M
+  Welcome to Open Firmware^M
+^M
+  Copyright (c) 2004, 2017 IBM Corporation All rights reserved.^M
+  This program and the accompanying materials are made available^M
+  under the terms of the BSD License available at^M
+  http://www.opensource.org/licenses/bsd-license.php^M
+^M
+^M
+Trying to load: -s verbose from: /pci@800000020000000/scsi@2/disk@100000000000000 ...   Successfully loaded^M
+^M
+                        ---> qemu,pseries detected <---^M
+^M
+^M
+^M
+^M
+^M
+^M
+^M
+-------------------------------------------------------------------------------^M
+                                Welcome to AIX.^M
+                   boot image timestamp: 05:56:13 04/20/2019^M
+        processor count: 1;  memory size: 4096MB;  kernel size: 38426884^M
+         boot device: /pci@800000020000000/scsi@2/disk@100000000000000^M
+^M
+8000FFEC bytes of free memory remain at address 7FFF0014^M
+load address: 0x00004000   aixmon size: 0x000D2C00   boot image size: 0x01A6B430^M
+^LAIX vm,uuid property contains invalid data^Mload address: 0x00004000   aixmon size: 0x000D2C00   boot image size: 0x01A6B430^M
+^LAIX vm,uuid property contains invalid data^M
+get_ppp return code: 0xFFFFFFFE^M
+^M
+AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument^M
+The temporary memory region list is at 1 percent capacity.^M
+The temporary IPLCB is at 1 percent capacity.^M
+The IPLCB address is 0x0FFF9000^M
+name                 offset           size^M
+ipl_cb_and_bit_map 00000000 ......00005958^M
+bit_map........... 00000790 ......00000006^M
+ipl_info.......... 000001C8 ......00000024^M
+splpar_info....... 000001EC ......00000048^M
+system_info....... 00000234 ......000000C4^M
+processor_info.... 000002F8 ......00000148^M
+lpar_id_info...... 00000440 ......00000088^M
+dr_proc_info...... 000004C8 ......00000008^M
+dr_mem_info....... 000004D0 ......00000028^M
+lpar_info......... 000004F8 ......00000014^M
+segment page...... 00000518 ......00000028^M
+processor page.... 00000540 ......00000010^M
+res_asso_id....... 00000550 ......00000050^M
+res_asso_group.... 000005A0 ......00000048^M
+asso_ref_pnt...... 000005E8 ......00000010^M
+residual.......... 00000820 ......00005138^M
+fwad_info......... 000005F8 ......00000040^M
+contig mem rsv.... 00000738 ......00000058^M
+    region address      region length       attr  label^M
+0   0x0000000000000000  0x000000000FFF7000  0x01  0x01^M
+1   0x000000000FFF7000  0x0000000000002000  0x01  0x03^M
+2   0x000000000FFF9000  0x0000000000006000  0x01  0x02^M
+3   0x000000000FFFF000  0x0000000000000014  0x00  0x05^M
+4   0x000000000FFFF014  0x00000000F0000FEC  0x01  0x01^M
+5   0x0000000100000000  0xFFFFFFFF00000000  0x00  0x07^M
+----------------------------^M
+^M
+0000012C bytes of free memory remain at address 00004000^M
+compressed kernel addr: D6C00;  sz: 98CE33;  uncompressed kernel addr:  1DB59600^M
+         name     source       dest       size   flags^M
+ 0      .data   1e6f9840    2000000    12bdd20     1^M
+ 1    basecfg    1b04000    fff5000       15d9     1^M
+ 2      ramfs     a63a30    efe9000    100b82a     1^M
+ 3      .text   1db59840      d6c00     ba0000     1^M
+ 4       .ldr   1f9b7560     c77000      a9523     1^M
+ 5     symtab   1fe0aaf4     d21000     1f4410     1^M
+ 6  kern. hdr   1db59600          0        240     1^M
+ 7       .bss          0    32bdd20    27222e0     2^M
+free space between BSS and RAM filesystem: 09609000^M
+^M
+entry_point: 0x000D6C28^M
+                       kernel debugger setting: enabled^M
+-------------------------------------------------------------------------------^M
+^LStarLED{A20}^M
+Data Storage Interrupt - PROC^M
+.dispatch+000098              lwz    r0,1830(r6)         r0=0,1830(r6)=F00000002FF48E30^M
+KDB(0)>
+
+(apologies for all the ^M - they are emitted by qemu or AIX - not sure)
+
+Using the same command to boot AIX from 3.1.0 works (no DSI Interrupt). - Other problems occur later, but no Kernel interrupt, only user space problems - and that's another problem - but one at a time !
+
+--Ivan
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1831477 b/results/classifier/gemma3:12b/boot/1831477
new file mode 100644
index 000000000..285a31962
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1831477
@@ -0,0 +1,7 @@
+
+update edk2 submodule & binaries to edk2-stable201905
+
+The edk2 project will soon release edk2-stable201905. Update the edk2 submodule in QEMU, and the bundled edk2 binaries, accordingly.
+
+https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201905-tag-planning
+https://github.com/tianocore/edk2/releases/tag/edk2-stable201905 [upcoming link]
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1835477 b/results/classifier/gemma3:12b/boot/1835477
new file mode 100644
index 000000000..6ceb8274d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1835477
@@ -0,0 +1,6 @@
+
+Converting qcow2 to vmdk on MacOSX results in a non-bootable image
+
+When using qemu-img convert -O vmdk  with version 3.1.0 or 4.0.0 on OSX (10.14.3) with a qcow2 image  (https://cloud-images.ubuntu.com/bionic/20190703/bionic-server-cloudimg-amd64.img), the resulting image is not bootable.
+
+Running the same command on Ubuntu 18.04 results in a bootable image as expected
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1835793 b/results/classifier/gemma3:12b/boot/1835793
new file mode 100644
index 000000000..626e6e465
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1835793
@@ -0,0 +1,12 @@
+
+Running an edk2 based bios
+
+This is not necessarily a bug, however I wasn't sure were to get help.
+
+I am currently working on using QEMU  to run a BIOS my company has developed. In order to see if the software was working correctly, I was able to successfully run the edk2 bios using the following command:
+
+qemu-system-x86_64.exe -bios "C:\Users\matthew.intriago\Desktop\ovmf.fd" -net none
+
+However, when running the same command using  our personalized bios, QEMU launches stating that “guest has not initialized display”. Theoretically, QEMU should be able to run the bios since it is edk2 based, the only difference between the two is that our bios has more features. 
+
+If anyone has any insight on what the issue might be I would greatly appreciate any help.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1836 b/results/classifier/gemma3:12b/boot/1836
new file mode 100644
index 000000000..9e4aa1316
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1836
@@ -0,0 +1,2 @@
+
+AIX no longer boots
diff --git a/results/classifier/gemma3:12b/boot/1836136 b/results/classifier/gemma3:12b/boot/1836136
new file mode 100644
index 000000000..5c9080ad7
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1836136
@@ -0,0 +1,4 @@
+
+u-boot: any plans to update u-boot to v2019.07
+
+Just want to pulse about the plan to update u-boot binary to latest v2019.07.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1838465 b/results/classifier/gemma3:12b/boot/1838465
new file mode 100644
index 000000000..3c970a626
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1838465
@@ -0,0 +1,10 @@
+
+qemu-system-x86_64 kernel panic 30% of the time starting up VM
+
+I have created a Fedora Core 5 x86_64 VM image. When I run the image using QEMU on Windows the VM hangs while loading the kernel about 30% of the time. I am trying to use this VM with a CI software, looking at the history the build failed 27 out of 79 attempts. QEMU 3.0.0 is installed on the CI machine. I have tried using the exact same image using QEMU on Linux (Ubuntu) and found the image boot successful every time (40+ attempts). The VM image is fairly old it was created using QEMU 0.11.1.
+
+I have tried multiple versions on QEMU on windows; 0.11.1, 2.12.1, and 3.0.0 all of them fail randomly. I can reproduce the issue on several different Windows 10 computers.
+
+The command I am using to start the VM is “qemu-system-x86_64.exe -cpu qemu64 -smp cores=2 -device e1000,netdev=net0 -boot menu=off -m 1G -drive `"file=C:\qimages\Fedora-Core-5-x64.qcow2,index=0,media=disk`" -snapshot -netdev user,id=net0,hostfwd=tcp::10022-:22”
+
+I can provide the qcow image but it is somewhat large coming it at 4.15GB so I’m not sure what would be the best way to transfer it.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1838658 b/results/classifier/gemma3:12b/boot/1838658
new file mode 100644
index 000000000..2a958eb9f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1838658
@@ -0,0 +1,14 @@
+
+qemu 4.0.0 broken by glib update
+
+In brief, an install CD will successfully boot with qemu 4.0.0 built with glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I tracked it down to glib's GHashTable improvements. qemu is happy with a glib built from
+```
+ git checkout -f 2.60.4
+ git revert --no-edit 86c6f7e2b..3bed8a13b
+ git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159
+ git revert --no-edit 603fb5958..d3074a748
+ git revert --no-edit 0b45ddc55..0600dd322
+```
+When the GHashTable improvements were committed, there was already a preemptive note about any breakage being due to using private implementation details, hence mentioning it here rather than with glib.
+
+For the full saga, see: http://gnats.netbsd.org/54310
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1840719 b/results/classifier/gemma3:12b/boot/1840719
new file mode 100644
index 000000000..3e6477503
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1840719
@@ -0,0 +1,12 @@
+
+win98se floppy fails to boot with isapc machine
+
+QEMU emulator version 4.1.50 (commit 50d69ee0d)
+
+floppy image from:
+https://winworldpc.com/download/417d71c2-ae18-c39a-11c3-a4e284a2c3a5
+
+$ qemu-system-i386 -M isapc -fda Windows\ 98\ Second\ Edition\ Boot.img
+SeaBIOS (version rel-1.12.1-0...)
+Booting from Floppy...
+Boot failed: could not read the boot disk
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1849 b/results/classifier/gemma3:12b/boot/1849
new file mode 100644
index 000000000..8a7de2cc0
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1849
@@ -0,0 +1,72 @@
+
+Problems with building riscv Linux using qemu on wsl2
+Description of problem:
+execute:
+
+`qemu-system-riscv64 -M virt -m 256M -nographic -kernel /home/ysc/test/linux-6.1.46/arch/riscv/boot/Image -drive file=rootfs.img,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -append "root=/dev/vda rw console=ttyS0"`
+
+**appear:**
+
+OpenSBI
+
+/ \_\_ \\ / **_| \_ \_ | | | | | \_\_ \__\_ \_ \_\_ | (_**\_ | |_) || | | | | | '\_ \\ / \_ \\ '\_ \\ \__\_ | \_ \< | | | |\*\*| | |_) | \_\_/ | | |) | |) || | \_\_**/| .**/ \_\*\*|_| |_|**_/|\___\_/_**| | | |\_|
+
+Platform Name : riscv-virtio,qemu
+
+Platform Features : medeleg Platform HART Count : 1
+
+Platform IPI Device : aclint-mswi
+
+Platform Timer Device : aclint-mtimer @ 10000000Hz
+
+Platform Console Device : uart8250 Platform HSM Device : ---
+
+Platform Reboot Device : sifive_test Platform Shutdown Device : sifive_test
+
+Firmware Base : 0x80000000
+
+Firmware Size : 252 KB
+
+Runtime SBI Version : 0.3
+
+Domain0 Name : root
+
+Domain0 Boot HART : 0
+
+Domain0 HARTs : 0\*
+
+Domain0 Region00 : 0x0000000002000000-0x000000000200ffff (I)
+
+Domain0 Region01 : 0x0000000080000000-0x000000008003ffff ()
+
+Domain0 Region02 : 0x0000000000000000-0xffffffffffffffff (R,W,X)
+
+Domain0 Next Address : 0x0000000080200000 Domain0 Next Arg1 : 0x000000008f000000
+
+Domain0 Next Mode : S-mode Domain0 SysReset : yes
+
+Boot HART ID : 0
+
+Boot HART Domain : root
+
+Boot HART ISA : rv64imafdcsuh
+
+Boot HART Features : scounteren,mcounteren,time
+
+Boot HART PMP Count : 16
+
+Boot HART PMP Granularity : 4
+
+Boot HART PMP Address Bits: 54
+
+Boot HART MHPM Count : 0
+
+Boot HART MIDELEG : 0x0000000000001666
+
+Boot HART MEDELEG : 0x0000000000f0b509
+
+When I run qemu, it's stuck here
+Steps to reproduce:
+1. Build the kernel file using Linux-6.1.46
+2. Use busbox to build rootfs
+3. run qemu
diff --git a/results/classifier/gemma3:12b/boot/1849234 b/results/classifier/gemma3:12b/boot/1849234
new file mode 100644
index 000000000..36b787731
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1849234
@@ -0,0 +1,4 @@
+
+Macos Catalina bug
+
+When I want to boot anything with qemu it just stops responding.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1851552 b/results/classifier/gemma3:12b/boot/1851552
new file mode 100644
index 000000000..e0156b978
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1851552
@@ -0,0 +1,16 @@
+
+since ubuntu 18 bionic release and latest, the ubuntu18 cloud image is unable to boot up on openstack instance 
+
+Openstack Queens release which is running on ubuntu 18 LTS Controller and Compute.
+Tried to boot up the instance via horizon dashboard without success.
+Nova flow works perfect.
+When access to console I discovered that the boot process stuck in the middle.
+[[0;1;31m TIME [0m] Timed out waiting for device dev-vdb.device.
+[[0;1;33mDEPEND[0m] Dependency failed for /mnt.
+[[0;1;33mDEPEND[0m] Dependency failed for File System Check on /dev/vdb.
+It receives IP but looks like not get configured at time.
+since ubuntu 18 there is netplan feature managing the network interfaces
+please advise.
+
+more details as follow:
+https://bugs.launchpad.net/networking-calico/+bug/1851548
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1852196 b/results/classifier/gemma3:12b/boot/1852196
new file mode 100644
index 000000000..19d805c1e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1852196
@@ -0,0 +1,25 @@
+
+update edk2 submodule & binaries to edk2-stable202008
+
+edk2-stable201911 will be tagged soon:
+
+  https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning
+
+  https://github.com/tianocore/edk2/releases/tag/edk2-stable201911
+  [upcoming link]
+
+It should be picked up by QEMU, after the v4.2.0 release.
+
+Relevant fixes / features in edk2, since edk2-stable201905 (which is
+what QEMU bundles at the moment, from LP#1831477):
+
+- enable UEFI HTTPS Boot in ArmVirtQemu* platforms
+  https://bugzilla.tianocore.org/show_bug.cgi?id=1009
+  (this is from edk2-stable201908)
+
+- fix CVE-2019-14553 (Invalid server certificate accepted in HTTPS Boot)
+  https://bugzilla.tianocore.org/show_bug.cgi?id=960
+
+- consume OpenSSL-1.1.1d, for fixing CVE-2019-1543, CVE-2019-1552 and
+  CVE-2019-1563
+  https://bugzilla.tianocore.org/show_bug.cgi?id=2226
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1853083 b/results/classifier/gemma3:12b/boot/1853083
new file mode 100644
index 000000000..dc1a6fd62
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1853083
@@ -0,0 +1,4 @@
+
+qemu ppc64 4.0 boot AIX5.1 hung
+
+When boot AIX5.1 from cdrom device, qemu hung there, no further info is displayed and cpu consumption is high.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1853429 b/results/classifier/gemma3:12b/boot/1853429
new file mode 100644
index 000000000..c503008ec
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1853429
@@ -0,0 +1,9 @@
+
+qemu-kvm on aarch64 attach volume failed when vm is booting
+
+I use libvirt and qemu-kvm on aarch64 platform to attach volume to a booting vm，when the system of vm has not boot up, attach volume will be failed, after vm system booting up, attach volume can be successful.
+
+libvirt: 4.5.0
+qemu : 2.12.0
+
+console log and qemu command of vm is in attachment.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1854577 b/results/classifier/gemma3:12b/boot/1854577
new file mode 100644
index 000000000..5ffcc5930
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1854577
@@ -0,0 +1,12 @@
+
+unable to boot arm64 image
+
+Hi
+
+Now I facing boot linux-5.3 arm64 image failed, without any log, just hang here.
+
+Host machine: ubuntu-18.04 with 4.15.0-70-generic kernel
+Qemu version: qemu-system-aarch64-version 4.1.0
+use command: qemu-system-aarch64 -kernel <IAMGE> -append "console=ttyAMA0" -m 2048M -smp 2 -M virt -cpu cortex-a57 -nographic
+
+could anyone teach me how to debug this?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1855002 b/results/classifier/gemma3:12b/boot/1855002
new file mode 100644
index 000000000..f0c127b35
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1855002
@@ -0,0 +1,26 @@
+
+Cannot boot arm kernel images on s390x
+
+While running the acceptance tests on s390x, the arm tests under qemu/tests/acceptance/boot_linux_console.py will timeout, except the test using u-boot. All the arm tests run without problems on x86 and ppc.
+
+This test boots the kernel and wait for a kernel panic to make sure it can boot that kind of kernel on the host running the test. The URL for the kernels are available inside the python test code, but I'm listing them here:
+
+Fail: https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/29/Everything/armhfp/os/images/pxeboot/vmlinuz
+Fail: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb
+Fail: https://snapshot.debian.org/archive/debian/20190928T224601Z/pool/main/l/linux/linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb
+Pass: https://raw.githubusercontent.com/Subbaraya-Sundeep/qemu-test-binaries/fa030bd77a014a0b8e360d3b7011df89283a2f0b/spi.bin
+
+I tried to manually investigate the problem with the first kernel of the list. The command I used to try to boot it was:
+
+/home/linux1/src/v4.2.0-rc3/bin/qemu-system-arm -serial stdio -machine virt -kernel /home/linux1/venv/python3/data/cache/by_location/1d5fdf8018e79b806aa982600c0866b199946efc/vmlinuz
+-append "printk.time=0 console=ttyAMA0"
+
+On an x86 machine, I can see it boots and ends with a kernel panic as expected. On s390x, it just hangs.
+
+I also tried to debug with gdb, redirecting the monitor and the serial console to other terminal sessions without success.
+
+QEMU version is the latest as of today,tag v4.2.0-rc4, commit 1bdc319ab5d289ce6b822e06fb2b13666fd9278e.
+
+s390x system is a Red Hat Enterprise Linux Server 7.7 running as a z/VM 6.4.0 guest at IBM LinuxONE Community Cloud.
+
+x86 system is a Fedora 31 running on Intel i7-8650U.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1857143 b/results/classifier/gemma3:12b/boot/1857143
new file mode 100644
index 000000000..d9b937aa6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1857143
@@ -0,0 +1,16 @@
+
+VMs won't boot from external snapshots on qemu 4.2
+
+After upgrading from qemu 4.1.1-1 to 4.2.0-1, VMs that were set to use an external snapshot as their disk failed to boot. 
+
+Depending on the guest OS and other VM settings the boot fails and you get either the "Boot failed: not a bootable drive" message or the grub rescue shell or the EFI shell. Downgrading back to qemu 4.1 allows the VMs to boot from the external snapshots without any problem and the disk images doesn't appear to be corrupted afterwards.
+
+From my testing this bug is easily reproducible. Create a VM, install a guest os, confirm that the VM boots the guest os without problems, shutdown the VM, create an external snapshot of the VM disk, set the VM to boot from the snapshot, try to boot the VM with qemu 4.2 and see it fail, try to boot it with qemu 4.1 and see it succeed.
+
+In my case, to test that this bug is reproducible, I used virt-manager to install Xubuntu 19.10 on a qcow2 disk image, and then used qemu-img create -f qcow2 -b base_image.qcow2 snapshot_image.qcow2 to create the external snapshot and edited the xml in virt-manager to point the VM's disk to snapshot_image.qcow2. It failed to boot with qemu 4.2, but it was working fine with 4.1.
+
+I booted this test VM off a live distro using the virtual CDROM and fdisk can't seem to find a partition table on the VM disk when qemu 4.2 is used, with 4.1 it can see the partition table just fine.
+
+Internal snapshots don't seem to have this problem.
+
+I'm using Archlinux, virt-manager 2.2.1-2, libvirt 5.10.0-1, qemu 4.2.0-1.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1858814 b/results/classifier/gemma3:12b/boot/1858814
new file mode 100644
index 000000000..48edc1012
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1858814
@@ -0,0 +1,14 @@
+
+'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
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1859 b/results/classifier/gemma3:12b/boot/1859
new file mode 100644
index 000000000..abdc6da1b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1859
@@ -0,0 +1,9 @@
+
+Trying to boot Windows Server 2008 Windows Host
+Description of problem:
+On Windows 10 trying to boot Windows Server 2008 R2 I am just stuck on starting Windows if I do get past Starting Windows it just goes to 0x0000007F BSOD
+Steps to reproduce:
+1. Run Windows Server with my command line input
+2. Stuck on Starting Windows
+Additional information:
+![Capture](/uploads/d46fb1980c1b57fed6e0b7d1af98fbaa/Capture.PNG)
diff --git a/results/classifier/gemma3:12b/boot/1859106 b/results/classifier/gemma3:12b/boot/1859106
new file mode 100644
index 000000000..18c5cf8f3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1859106
@@ -0,0 +1,6 @@
+
+4.2 regression: ReactOS crashes on boot
+
+In QEMU 4.1.x and earlier, ReactOS can successfully boot, but starting with 4.2, it fails, instead coming up with an error "The video driver failed to initialize."
+
+This happens regardless of VM configuration (even -M pc-i440fx-4.1) and it works well with older versions of QEMU. bisecting QEMU to find the first bad commit reveals 0221d73ce6a8e075adaa0a35a6ef853d2652b855 as the culprit, which is updating the seabios version; perhaps this bug belongs there, but I don't know the appropriate avenue (it seems seabios is a subproject of QEMU anyway?).
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1859656 b/results/classifier/gemma3:12b/boot/1859656
new file mode 100644
index 000000000..ada5e557f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1859656
@@ -0,0 +1,43 @@
+
+Unable to reboot s390x KVM machine after initial deploy
+
+MAAS version: 2.6.1 (7832-g17912cdc9-0ubuntu1~18.04.1)
+Arch: S390x
+
+Appears that MAAS can not find the s390x bootloader to boot from the disk, not sure how maas determines this.  However this was working in the past. I had originally thought that if the maas machine was deployed then it defaulted to boot from disk, (Which does work as expected) 
+
+
+Reproduce: 
+
+- Deploy Disco on S390x KVM instance
+- Reboot it
+
+on the KVM console...
+
+Connected to domain s2lp6g001
+Escape character is ^]
+done
+  Using IPv4 address: 10.246.75.160
+  Using TFTP server: 10.246.72.3
+  Bootfile name: 'boots390x.bin'
+  Receiving data:  0 KBytes
+  TFTP error: file not found: boots390x.bin
+Trying pxelinux.cfg files...
+  Receiving data:  0 KBytes
+  Receiving data:  0 KBytes
+Failed to load OS from network
+
+
+==> /var/log/maas/rackd.log <==
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] boots390x.bin requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/65a9ca43-9541-49be-b315-e2ca85936ea2 requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/01-52-54-00-e5-d7-bb requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64BA0 requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64BA requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64B requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF64 requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF6 requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0AF requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0A requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/0 requested by 10.246.75.160
+2020-01-14 18:21:24 provisioningserver.rackdservices.tftp: [info] s390x/default requested by 10.246.75.160
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1860742 b/results/classifier/gemma3:12b/boot/1860742
new file mode 100644
index 000000000..7eddf6263
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1860742
@@ -0,0 +1,34 @@
+
+xv6 Bootloop
+
+Qemu Version: 4.2.0
+
+Launch command: 
+qemu-system-x86_64 -nographic -drive file=fs.img,index=1,media=disk,format=raw -drive file=xv6.img,index=0,media=disk,format=raw -smp 2 -m 512
+
+How to reproduce? 
+1.)  Use/install latest release of qemu (4.2.0 at time of writing)
+
+2.)  Download, build, and run xv6 (a simple os designed for learning operating systems fundamentals)
+
+cd /tmp
+git clone https://github.com/mit-pdos/xv6-public.git
+cd xv6-public
+make qemu-nox
+
+3.)  Qemu should now bootloop (seem to try to boot but then just repeat). This is what it looks like below before it repeats:
+
+SeaBIOS (version ?-20191223_100556-anatol)
+
+iPXE (http://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+1FF92A50+1FEF2A50 CA00
+                                                                               
+Booting from Hard Disk..
+
+
+
+Host: Arch Linux - Kernel version: 5.4.13
+Guest: xv6 (https://github.com/mit-pdos/xv6-public)
+
+Suspicion:
+
+When I was using qemu 2.11.1 inside docker, the xv6 os booted with no problem. I am thinking that something changed between Qemu 2.11.1 and Qemu 4.2.0 which is now causing boot problems.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1860914 b/results/classifier/gemma3:12b/boot/1860914
new file mode 100644
index 000000000..fada6285e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1860914
@@ -0,0 +1,14 @@
+
+QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification
+
+When QEMU is launched with the -kernel option to boot a Multiboot image, the command line passed in the -append option is additionally prefixed the pathname of the kernel image and a space. Likewise, module command lines passed in the -initrd option are passed with the module pathname and a space prepended. At the very least the former is contary to what is prescribed in the Multiboot specification, version 0.6.96[0], which says in §3.3:
+
+> General-purpose boot loaders should allow user a complete control on command line independently of other factors like image name.
+
+With respect to module command lines, the spec is less clear, but GNU GRUB2 (the de facto reference implementation) does not prepend pathnames to command lines of either. I haven't tested GRUB legacy, but I assume it exhibits the same behaviour. It would be strange if passing pathnames was in fact intended; bootloader pathnames are useless to the loaded kernel, which may potentially have a completely different view of the file system from the bootloader.
+
+Also, given that a kernel pathname may contain spaces, skipping it in the command line cannot be done reliably, while loading a Multiboot module from a pathname that contains spaces is outright impossible.
+
+Found in 4.2.0, but latest git master apparently behaves the same.
+
+[0]: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1862110 b/results/classifier/gemma3:12b/boot/1862110
new file mode 100644
index 000000000..2aba7f137
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1862110
@@ -0,0 +1,67 @@
+
+qemu in script is not parsing properly
+
+Bug Report: 
+>>qemu-system-x86_64 --version: QEMU emulator version 4.2.0
+>>Arch-linux version 2020.02.01
+I was following a tutorial on how to make a windows vm and i have encountered and issue in the settings of my script I have listed below.
+
+The commented code directly above the uncommented qemu instance would boot the Windows screen but the issue arises when I try to reach the same code block under the commented setting lines which takes me to the default SeaBIOS loader.
+
+ 
+#!/bin/bash
+
+vmname="windows10vm"
+
+if ps -ef | grep qemu-system-x86_64 | grep -q multifunction=on; then
+echo "A passthrough VM is already running." &
+exit 1
+
+else
+
+# use pulseaudio
+
+export QEMU_AUDIO_DRV=pa
+export QEMU_PA_SAMPLES=8192
+export QEMU_AUDIO_TIMER_PERIOD=99
+export QEMU_PA_SERVER=/run/user/1000/pulse/native
+
+cp /usr/share/ovmf/x64/OVMF_VARS.fd /tmp/my_vars.fd
+
+#qemu-system-x86_64 \
+#-drive id=disk0,if=virtio,cache=none,format=raw,file=.../IMGs/win.img \
+#-drive file=.../ISOs/Win10_1909_English_x64.iso,index=1,media=cdrom \
+
+qemu-system-x86_64 \
+
+#-name $vmname,process=$vmname \
+#-machine type=q35,accel=kvm \
+#-cpu host,kvm=off \
+#-smp 4,sockets=1,cores=3,threads=1 \
+#-m 8G \
+#-balloon none \
+#-rtc clock=host,base=localtime \
+#-vga none \
+#-nographic \
+#-serial none \
+#-parallel none \
+#-soundhw hda \
+#-usb \
+#-device usb-host,vendorid=...,productid=... \
+#-device usb-host,vendorid=...,productid=... \
+#-device vfio-pci,host=...,multifunction=on \
+#-device vfio-pci,host=... \
+#-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_VARS.fd \
+#-drive if=pflash,format=raw,file=/tmp/my_vars.fd \
+#-boot order= dc \
+
+-drive id=disk0,if=virtio,cache=none,format=raw,file=.../IMGs/win.img \
+-drive file=.../ISOs/Win10_1909_English_x64.iso,index=1,media=cdrom \
+-drive file=.../ISOs/virtio-0.1.171.iso,index=2,media=cdrom \
+
+#-netdev type=tap,id=net0,ifname=vmtap0,vhost=on \
+#-device virtio-net-pci,netdev=net0,mac=... \
+
+exit 0
+
+fi
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1865626 b/results/classifier/gemma3:12b/boot/1865626
new file mode 100644
index 000000000..c323ed5ee
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1865626
@@ -0,0 +1,26 @@
+
+s390x guest hang when ipl boot from a mdev dasd
+
+qemu latest
+kernel 5.3.18
+
+I am using a passthrough dasd as boot device, the installment looks fine and gets into reboot process. However VM could not boot and just hang as below after that. I have been checking on "s390: vfio-ccw dasd ipl support" series right now but no clue yet. Could anyone take a look for it? Thanks.
+
+
+
+s390vsw188:~ # bash test.sh
+LOADPARM=[        ]
+executing ccw chain at : 0x0000000000000018
+executing ccw chain at : 0x000000000000e000
+
+2020-03-01T06:24:56.879314Z qemu-system-s390x: warning: vfio-ccw (devno fe.0.0000): PFCH flag forced
+
+
+
+s390zp12:~ # cat test.sh
+/root/qemu/s390x-softmmu/qemu-system-s390x \
+-machine s390-ccw-virtio,accel=kvm \
+-nographic \
+-bios /root/qemu/pc-bios/s390-ccw/s390-ccw.img \
+-device vfio-ccw,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/08e8c006-146d-48d3-b21a-c005f9d3a04b,,devno=fe.0.0000,bootindex=1 \
+-global vfio-ccw.force-orb-pfch=yes \
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/187 b/results/classifier/gemma3:12b/boot/187
new file mode 100644
index 000000000..3a76e5f12
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/187
@@ -0,0 +1,2 @@
+
+Cannot boot arm kernel images on s390x
diff --git a/results/classifier/gemma3:12b/boot/1874264 b/results/classifier/gemma3:12b/boot/1874264
new file mode 100644
index 000000000..ad7e68859
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1874264
@@ -0,0 +1,359 @@
+
+AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu
+
+kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version
+QEMU emulator version 4.2.93 (v5.0.0-rc3-8-g3119154db0-dirty)
+Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
+
+qemu-system-ppc64 \
+  -name "IBM AIX - IBM POWER9" \
+  -M pseries \
+  -cpu POWER9 \
+  -smp 8 \
+  -m 8192 \
+  -nodefaults \
+  -nographic \
+  -prom-env input-device=/vdevice/vty@71000000 \
+  -prom-env output-device=/vdevice/vty@71000000 \
+  -serial tcp::9019,server,nowait \
+  -monitor tcp::9020,server,nowait \
+  -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \
+  -device virtio-net-pci,netdev=mynet0 \
+  -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \
+  -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \
+  -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe
+
+-------------------------------------------------------------------------------
+                                Welcome to AIX.
+                   boot image timestamp: 14:18:40 03/27/2020
+        processor count: 8;  memory size: 8192MB;  kernel size: 45422205
+         boot device: /pci@800000020000000/scsi@1/disk@100000000000000
+AIX vm,uuid property contains invalid data
+processing splpar characteristic: MaxEntCap
+processing splpar characteristic: DesMem
+processing splpar characteristic: DesProcs
+processing splpar characteristic: MaxPlatProcs
+processing splpar characteristic: HostThrs
+
+AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument
+-------------------------------------------------------------------------------
+Starqemu-system-ppc64: OS terminated: 888 102 700 C20
+
+
+qemu-system-ppc64 \
+  -name "IBM AIX - IBM POWER8" \
+  -M pseries \
+  -cpu POWER8 \
+  -smp 8 \
+  -m 8192 \
+  -nodefaults \
+  -nographic \
+  -prom-env input-device=/vdevice/vty@71000000 \
+  -prom-env output-device=/vdevice/vty@71000000 \
+  -serial tcp::9019,server,nowait \
+  -monitor tcp::9020,server,nowait \
+  -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \
+  -device virtio-net-pci,netdev=mynet0 \
+  -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \
+  -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \
+  -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe
+
+-------------------------------------------------------------------------------
+                                Welcome to AIX.
+                   boot image timestamp: 14:18:40 03/27/2020
+        processor count: 8;  memory size: 8192MB;  kernel size: 45422205
+         boot device: /pci@800000020000000/scsi@1/disk@100000000000000
+AIX vm,uuid property contains invalid data
+processing splpar characteristic: MaxEntCap
+processing splpar characteristic: DesMem
+processing splpar characteristic: DesProcs
+processing splpar characteristic: MaxPlatProcs
+processing splpar characteristic: HostThrs
+
+AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument
+-------------------------------------------------------------------------------
+Star**
+ERROR:/home/kens/tmp/qemu/cpus.c:1727:qemu_tcg_cpu_thread_fn: assertion failed: (cpu->halted)
+
+
+kens@LAPTOP-JN77KAC2$ qemu-system-ppc64 -version
+QEMU emulator version 2.11.2
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+qemu-system-ppc64 \
+  -name "IBM AIX - IBM POWER9" \
+  -M pseries,cap-htm=off \
+  -cpu POWER9 \
+  -smp 8 \
+  -m 8192 \
+  -nodefaults \
+  -nographic \
+  -prom-env input-device=/vdevice/vty@71000000 \
+  -prom-env output-device=/vdevice/vty@71000000 \
+  -serial tcp::9019,server,nowait \
+  -monitor tcp::9020,server,nowait \
+  -netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9018-10.0.2.18:22 \
+  -device virtio-net-pci,netdev=mynet0 \
+  -drive file=images/aix-ppc64.img,format=qcow2,if=none,id=hd,media=disk,cache=unsafe \
+  -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \
+  -drive file=images/iso/blank-cdrom,format=raw,media=cdrom,cache=unsafe
+
+-------------------------------------------------------------------------------
+                                Welcome to AIX.
+                   boot image timestamp: 14:18:40 03/27/2020
+        processor count: 8;  memory size: 8192MB;  kernel size: 45422205
+         boot device: /pci@800000020000000/scsi@1/disk@100000000000000
+AIX vm,uuid property contains invalid data
+processing splpar characteristic: MaxEntCap
+processing splpar characteristic: DesMem
+processing splpar characteristic: DesProcs
+processing splpar characteristic: MaxPlatProcs
+
+AKVM: hcall-multi-tce detected but overridden, allow with "multce" boot argument
+-------------------------------------------------------------------------------
+Star
+0539
+0811
+0539
+0812
+0708
+0811
+0811
+0811
+0811
+0811
+0811
+0811
+0811
+078c
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+078c
+0539
+2071
+0539
+2073
+0539
+25b3vscsi_send_capabilities: capabilities size mismatch !
+VSCSI: Unknown MAD type 09
+
+0539
+0538
+0539
+0591
+0539
+0538
+0539
+0538
+0539
+25b0
+0539
+
+0511
+0551
+0517
+0517
+0517
+0517
+0553
+0517
+0517
+0538
+0539
+0538
+0539
+270b
+0539
+0538
+0539
+2070
+0539
+0538
+0539
+0811
+0539
+0811
+0539
+0812
+0708
+0811
+0811
+0811
+0811
+0811
+0811
+0811
+0811
+078c
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+25b6
+078c
+04ee
+078c
+0727
+0727
+2071
+2072
+2072
+2071
+0539
+25b3
+0539
+25b5
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0581
+0539
+0538
+0539
+7000
+0539
+0538
+0539
+0538
+0539
+0538
+0581
+0581
+0539
+0538
+0539
+25b0
+0539
+0538
+0539
+0538
+0539
+0731
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+0538
+0539
+2028
+0539
+0538
+0539
+
+0c33
+Saving Base Customize Data to boot disk
+Starting the sync daemon
+Starting the error daemon
+
+System initialization completed.
+TE=OFF
+CHKEXEC=OFF
+CHKSHLIB=OFF
+CHKSCRIPT=OFF
+CHKKERNEXT=OFF
+STOP_UNTRUSTD=OFF
+STOP_ON_CHKFAIL=OFF
+LOCK_KERN_POLICIES=OFF
+TSD_FILES_LOCK=OFF
+TSD_LOCK=OFF
+TEP=OFF
+TLP=OFF
+Successfully updated the Kernel Authorization Table.
+Successfully updated the Kernel Role Table.
+Successfully updated the Kernel Command Table.
+Successfully updated the Kernel Device Table.
+Successfully updated the Kernel Object Domain Table.
+Successfully updated the Kernel Domains Table.
+Successfully updated the Kernel RBAC log level.
+Successfully updated the Kernel RBAC log level.
+OPERATIONAL MODE Security Flags
+ROOT                      :    ENABLED
+TRACEAUTH                 :   DISABLED
+System runtime mode is now OPERATIONAL MODE.
+Setting tunable parameters...complete
+Checking for srcmstr active...complete
+Starting tcpip daemons:
+0513-059 The sendmail Subsystem has been started. Subsystem PID is 4456846.
+0513-059 The syslogd Subsystem has been started. Subsystem PID is 4522382.
+0513-059 The portmap Subsystem has been started. Subsystem PID is 4194776.
+0513-059 The inetd Subsystem has been started. Subsystem PID is 4129230.
+0513-059 The snmpmibd Subsystem has been started. Subsystem PID is 4325672.
+Finished starting tcpip daemons.
+
+
+AIX Version 7
+Copyright IBM Corporation, 1982, 2019.
+Console login: root
+root's Password:
+
+*******************************************************************************
+*                                                                             *
+*                                                                             *
+*  Welcome to AIX Version 7.2!                                                *
+*                                                                             *
+*                                                                             *
+*  Please see the README file in /usr/lpp/bos for information pertinent to    *
+*  this release of the AIX Operating System.                                  *
+*                                                                             *
+*                                                                             *
+*******************************************************************************
+Last login: Wed Apr 22 07:21:19 EDT 2020 on /dev/vty0
+
+root@aix-ppc64# oslevel -s
+7200-04-01-1939
+root@aix-ppc64#
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1879998 b/results/classifier/gemma3:12b/boot/1879998
new file mode 100644
index 000000000..827b46909
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1879998
@@ -0,0 +1,28 @@
+
+Bad check for return value of mmap()
+
+In
+./roms/skiboot/extract-gcov.c
+there is this code:
+
+        addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+        assert(addr != NULL);
+
+This check is wrong, mmap never returns NULL, on errors it returns MAP_FAILED (or -1). (Also sidenote: asserts usually shouldn't be used for error checking.)
+
+In
+roms/skiboot/libstb/print-container.c
+there's a similar issue:
+
+        payload = mmap(NULL, payload_st.st_size - SECURE_BOOT_HEADERS_SIZE,
+                        PROT_READ, MAP_PRIVATE, fdin, SECURE_BOOT_HEADERS_SIZE);
+        if (!payload)
+
+This if should be (payload == MAP_FAILED).
+
+Another one is in
+./roms/skiboot/libstb/create-container.c
+
+And in
+./roms/u-boot/tools/aisimage.c
+there's an mmap call that does not check the return value at all.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1881249 b/results/classifier/gemma3:12b/boot/1881249
new file mode 100644
index 000000000..3ec7edb1e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1881249
@@ -0,0 +1,10 @@
+
+CPU fetch from unpopulated ROM on reset
+
+Some architectures fetch the $PC/$SP register as vectors in memory, usually ROM.
+The CPU reset() handler is called before the ROM code is populated, resulting in fetching incorrect PC/SP.
+
+Architectures affected:
+- M68K
+- RX
+- ARM M-profile
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1882671 b/results/classifier/gemma3:12b/boot/1882671
new file mode 100644
index 000000000..48dcccc3a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1882671
@@ -0,0 +1,52 @@
+
+unbalanced UEFI TPL manipulations in iPXE with DOWNLOAD_PROTO_HTTPS enabled
+
+The version of QEMU (4.2.0) packaged for Ubuntu 20.04 hangs indefinitely at boot if an OVMF bios is used. This happens ONLY with qemu-system-x86_64. qemu-system-i386 works fine with the latest ia32 OVMF bios.
+
+NOTE[1]: the same identical OVMF bios works fine on QEMU 2.x packaged with Ubuntu 18.04.
+NOTE[2]: reproducing the fatal bug requires *no* operating system:
+
+   qemu-system-x86_64 -bios OVMF-pure-efi.fd
+
+On its window QEMU gets stuck at the very first stage:
+   "Guest has not initialized the display (yet)."
+
+NOTE[3]: QEMU gets stuck no matter if KVM is used or not.
+
+NOTE[4]: By adding the `-d int` option it is possible to observe that QEMU is, apparently, stuck in an endless loop of interrupts. For the first few seconds, registers' values vary quickly, but at some point they reach a final value, while the interrupt counter increments:
+
+  2568: v=68 e=0000 i=0 cpl=0 IP=0038:0000000007f1d225 pc=0000000007f1d225 SP=0030:0000000007f0c8d0 env->regs[R_EAX]=0000000000000000
+RAX=0000000000000000 RBX=0000000007f0c920 RCX=0000000000000000 RDX=0000000000000001
+RSI=0000000006d18798 RDI=0000000000008664 RBP=0000000000000000 RSP=0000000007f0c8d0
+R8 =0000000000000001 R9 =0000000000000089 R10=0000000000000000 R11=0000000007f2c987
+R12=0000000000000000 R13=0000000000000000 R14=0000000007087901 R15=0000000000000000
+RIP=0000000007f1d225 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+CS =0038 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-]
+SS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+DS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+FS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+GS =0030 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
+LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT
+TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy
+GDT=     00000000079eea98 00000047
+IDT=     000000000758f018 00000fff
+CR0=80010033 CR2=0000000000000000 CR3=0000000007c01000 CR4=00000668
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+CCS=0000000000000044 CCD=0000000000000000 CCO=EFLAGS  
+EFER=0000000000000d00
+
+
+NOTE[5]: Just to better help the investigation of the bug, I'd like to remark that the issue is NOT caused by an endless loop of triple-faults. I tried with -d cpu_reset and there is NO such loop. No triple fault whatsoever.
+
+NOTE[6]: The OVMF version used for the test has been downloaded from:
+https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20200515.1398.g6ff7c838d0.noarch.rpm
+
+but the issue is the same with older OVMF versions as well.
+
+
+Please take a look at it, as the bug is NOT a corner case. QEMU 4.2.0 cannot boot with an UEFI firmware (OVMF) while virtualizing a x86_64 machine AT ALL.
+
+Thank you very much,
+Vladislav K. Valtchev
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1883593 b/results/classifier/gemma3:12b/boot/1883593
new file mode 100644
index 000000000..1437e9241
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1883593
@@ -0,0 +1,10 @@
+
+Windows XP takes much longer to boot in TCG mode since 5.0
+
+Since upgrading from 4.2 to 5.0, a Windows XP VM takes much longer to boot.
+
+It hangs about three minutes on "welcome" screen with the blue background, while previously the total boot time was less than a minute. 
+
+The issue only happens in TCG mode (not with KVM) and also happens with the current master which includes the uring patches (7d3660e7).
+
+I can reproduce this issue with a clean XP install with no flags other than `-m 2G`. After booting, the performance seems to be normal.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1884425 b/results/classifier/gemma3:12b/boot/1884425
new file mode 100644
index 000000000..14e9c98f6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1884425
@@ -0,0 +1,12 @@
+
+MIPS64EL emu hangs at reboot
+
+QEMU Release version: 5.0.50 (v5.0.0-1411-g26bf4a2921-dirty)
+
+Full command line: qemu-system-mips64el -hda nt4svr.qcow2 -M magnum -L . -global ds1225y.filename=nvram  -global ds1225y.size=8200 -net nic -net user -cdrom en_winnt_4.0_svr.iso
+
+Host machine: Windows 10 1909 64-bit, QEMU running under WSL with the latest Kali distro and the latest Xming.
+
+Guest machine: MIPS64EL Magnum machine, no OS needs to be installed to reproduce - just change some stuff in the Setup program and try to exit
+
+Note: Custom ROM with Windows NT support used, NTPROM.RAW used from http://hpoussineau.free.fr/qemu/firmware/magnum-4000/setup.zip
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1885 b/results/classifier/gemma3:12b/boot/1885
new file mode 100644
index 000000000..8714aed37
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1885
@@ -0,0 +1,25 @@
+
+mipsel malta machine is broken in avocado console tests
+Description of problem:
+As noted in #1884 we see failures of the boot_linux_console.py test. Unlikely other avocado failures, these ones are consistent and reproduce locally with 100% success
+
+```
+./configure --target-list=mipsel-softmmu
+make -j 20
+cd build
+./pyvenv/bin/python3 -B -m avocado --show=app run --job-results-dir=./tests/results -t arch:mipsel --failfast tests/avocado/boot_linux_console.py:BootLinuxConsole.test_mips_malta32el_nanomips_4k
+```
+
+This test will reliably fail with a timeout waiting for console output.
+
+Attempting to run the QEMU command manually
+
+```
+$ ./qemu-system-mipsel -display none -vga none -machine malta -chardev stdio,id=console -serial chardev:console -cpu I7200 -no-reboot -kernel /home/berrange/src/virt/qemu/build/tests/results/job-2023-09-13T17.14-77de093/test-results/tmp_dir520smana/1-tests_avocado_boot_linux_console.py_BootLinuxConsole.test_mips_malta32el_nanomips_4kkernel -append 'printk.time=0 mem=256m@@0x0 console=ttyS0'
+```
+
+results in no serial console output at all.
+
+IMHO either the MIPS malta machine has had a regression, or the kernel we're downloading for testing has had a regression.
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/1887745 b/results/classifier/gemma3:12b/boot/1887745
new file mode 100644
index 000000000..2b1646183
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1887745
@@ -0,0 +1,26 @@
+
+call-method block-size failed with error ffffffdf
+
+I start Debian 10 PowerPC version in QEMU with this command :
+
+/usr/bin/qemu-system-ppc -monitor stdio -M mac99 -k fr -machine accel=tcg -m 512 -cdrom /home/david/Bureau/debian-10.0.0-powerpc-NETINST-1.iso -hda /home/david/Documents/Informatique et téléphone/Documentation informatique/Macintosh/Debian_10_LXDE -virtfs local,id=shared_folder_dev_0,path=/home/david/Bureau,security_model=none,mount_tag=shared0 -boot order=dc,menu=on -net nic,macaddr=00:a2:6d:80:10:8f,model=rtl8139 -net user -net user,smb=/home/david/Bureau -rtc base=localtime -name "Debian + LXDE sur iMac G3" -M mac99
+
+GRUB menu appears. Then, I choose "Default install", the screen is cleaned and "Loading..." appears. But after, nothing happens and I've got this error message :
+
+C>> annot manage 'undefined' PCI device type '<NULL>':
+>>  1af4 1009 (0 2 0)
+
+>> =============================================================
+>> OpenBIOS 1.1 [Mar 12 2020 14:02]
+>> Configuration device id QEMU version 1 machine id 1
+>> CPUs: 1
+>> Memory: 512M
+>> UUID: 00000000-0000-0000-0000-000000000000
+>> CPU type PowerPC,G4
+milliseconds isn't unique.
+>> switching to new context:
+>> call-method block-size failed with error ffffffdf
+>> call-method block-size failed with error ffffffdf
+
+
+I found this post, I don't know if it could help... : https://lists.gnu.org/archive/html/grub ... 00001.html
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1892441 b/results/classifier/gemma3:12b/boot/1892441
new file mode 100644
index 000000000..7fd643523
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1892441
@@ -0,0 +1,20 @@
+
+"No zIPL section in IPL2 record" error when emulating Debian 10.5.0 on s390x
+
+Hi,
+
+I want to emulate Debian 10.5.0 for the s390x architecture. 
+The Debian image is downloaded from the following link:
+https://cdimage.debian.org/debian-cd/current/s390x/iso-cd/debian-10.5.0-s390x-netinst.iso 
+
+Using the latest QEMU version 5.1.0, running the debian image using the given command:
+qemu-system-s390x -boot d -m 4096 -hda debian.qcow -cdrom debian-10.5.0-s390x-netinst.iso -nographic
+
+causes the error output below:
+
+LOADPARM=[        ]
+Using virtio-blk.
+Using guessed DASD geometry.
+Using ECKD scheme (block size  4096), CDL
+
+! No zIPL section in IPL2 record. !
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1892540 b/results/classifier/gemma3:12b/boot/1892540
new file mode 100644
index 000000000..249df14b2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1892540
@@ -0,0 +1,24 @@
+
+qemu can no longer boot NetBSD/sparc
+
+Booting NetBSD/sparc in qemu no longer works.  It broke between qemu version 5.0.0 and 5.1.0, and a bisection identified the following as the offending commit:
+
+  [5d971f9e672507210e77d020d89e0e89165c8fc9] memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"
+
+It's still broken as of 7fd51e68c34fcefdb4d6fd646ed3346f780f89f4.
+
+To reproduce, run
+
+  wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-sparc.iso
+  qemu-system-sparc -nographic -cdrom NetBSD-9.0-sparc.iso -boot d
+
+The expected behavior is that the guest boots to the prompt
+
+  Installation medium to load the additional utilities from:
+
+The observed behavior is a panic:
+
+  [   1.0000050] system[0]: trap 0x29: pc=0xf0046b14 sfsr=0xb6 sfva=0x54000000
+  [   1.0000050] cpu0: data fault: pc=0xf0046b14 addr=0x54000000 sfsr=0xb6<PERR=0x0,LVL=0x0,AT=0x5,FT=0x5,FAV,OW>
+  [   1.0000050] panic: kernel fault
+  [   1.0000050] halted
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1898883 b/results/classifier/gemma3:12b/boot/1898883
new file mode 100644
index 000000000..7d9ee2db2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1898883
@@ -0,0 +1,10 @@
+
+qemu-system-riscv64 failed to load binary kernel into memory
+
+QEMU Version: 5.1.0
+Compiled in Ubuntu 20.04 for riscv64, following the guide https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html.
+
+In qemu-system-riscv64, code at 0x80000000 will be executed by virtual CPU.
+For example, using `qemu-system-riscv64 -nographic -machine virt -bios none -kernel vmlinux -S -s`, my homebrew kernel(ELF file) will load at 0x80000000. If I strip the kernel using `riscv64-linux-gnu-objcopy -O binary vmlinux Image`, qemu-system-riscv64 will not load the binary machine code into the riscv64 load address, but `-bios Image` will.
+
+In `qemu-system-aarch64` compiled by Ubuntu team, I can use `qemu-system-aarch64 -M raspi3 -kernel Image_aarch64 -S -s` to load a specific machine code binary into 0x80000. And the elf kernel can be loaded to that address, too.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1903752 b/results/classifier/gemma3:12b/boot/1903752
new file mode 100644
index 000000000..f51cc5b26
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1903752
@@ -0,0 +1,11 @@
+
+qemu-system-avr error: qemu-system-avr: execution left flash memory
+
+I compiled QEMU 5.1 from source with target avr-softmmu. Running demo.elf from https://github.com/seharris/qemu-avr-tests/blob/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf (linked from https://www.qemu.org/docs/master/system/target-avr.html) yields the following error:
+
+$ ./qemu-5.1.0/avr-softmmu/qemu-system-avr -machine mega2560 -bios demo.elf
+VNC server running on 127.0.0.1:5900
+qemu-system-avr: execution left flash memory
+Aborted (core dumped)
+
+I compiled QEMU on Ubuntu Server 20.10 with gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1904206 b/results/classifier/gemma3:12b/boot/1904206
new file mode 100644
index 000000000..398977635
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1904206
@@ -0,0 +1,19 @@
+
+install QEMU
+
+I want install QEMU on Kali, I write : 
+
+qemu-system-arm -kernel ~/qemu_vms/kernel-qemu-3.10.25-wheezy -cpu arm1176 -m 256 -M versatilepb -serial stdio -append "root=/dev/sda2 rootfstype=ext4 rw" -hda ~/qemu_vms/2020-08-20-raspios-buster-armhf-full.img -nic user,hostfwd=tcp::5022-:22 -no-reboot
+
+The answer :
+
+WARNING: Image format was not specified for '/home/kali/qemu_vms/2020-08-20-raspios-buster-armhf-full.img' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+pulseaudio: set_sink_input_volume() failed
+pulseaudio: Reason: Invalid argument
+pulseaudio: set_sink_input_mute() failed
+pulseaudio: Reason: Invalid argument
+Uncompressing Linux... done, booting the kernel.
+
+I tried a lot of solutions but nothing worked. Please help
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1905037 b/results/classifier/gemma3:12b/boot/1905037
new file mode 100644
index 000000000..cb118c162
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1905037
@@ -0,0 +1,87 @@
+
+Qemu SPARC64 Panics on Sun Solaris 5.8 -  BOP_ALLOC failed
+
+Hi,
+
+Running Sun Solaris 5.8 by SPARC64, will panic by "BOP_ALLOC failed":
+
+$ qemu-system-sparc64 \
+  -drive file=sparc.qcow2,if=ide,bus=0,unit=0 \
+  -drive file=sun5.8.no1.iso,format=raw,if=ide,bus=1,unit=0,media=cdrom,readonly=on \
+  -boot d
+$ qemu-system-sparc64 -M sun4u -boot d -cdrom sun5.8.no1.iso -net nic -net user -m 2048
+
+Both commands will raise this error:
+
+OpenBIOS for Sparc64
+Configuration device id QEMU version 1 machine id 0
+kernel cmdline 
+CPUs: 1 x SUNW,UltraSPARC-IIi
+UUID: 00000000-0000-0000-0000-000000000000
+Welcome to OpenBIOS v1.1 built on Oct 28 2019 17:08
+  Type 'help' for detailed information
+Trying cdrom:f...
+Not a bootable ELF image
+Not a bootable a.out image
+
+Loading FCode image...
+Loaded 5936 bytes
+entry point is 0x4000
+Evaluating FCode...
+open isn't unique.
+Alloc of 0x2000 bytes at 0x16000 refused.
+
+panic[cpu0]/thread=10408000: BOP_ALLOC failed
+
+0000000010406ea0 unix:boot_alloc+44 (2000, 2000, 1000, 30000016000, 31002afd100, 30000014000)
+  %l0-3: 000000001041b2d0 0000030ffffff138 0000000000000001 000000001044bdc0
+  %l4-7: 000000001044af18 000000001044aef8 000000001044bd20 000000000000000b
+0000000010406f50 unix:segkmem_alloc+30 (30000016000, 2000, 0, 0, 1044efe0, 1044b300)
+  %l0-3: 0000030ffffff5c0 ffffffffffffe000 0000000000000000 000000001044bdc0
+  %l4-7: 000000001044af18 000000001044aef8 000000001044f840 000000001004a438
+0000000010407010 genunix:vmem_xalloc+3e4 (1044ea18, 1044ee20, ffffffffffffffff, ffffffffffffffff, 0, 0)
+  %l0-3: 000000001004a3b4 ffffffffffffe000 000000001044ea18 0000000000002000
+  %l4-7: 0000000000000000 0000000000000000 0000000000002000 000000001044ea38
+0000000010407140 genunix:kmem_slab_create+8c (0, 0, 2000, 300000043c0, 0, 1044ea18)
+  %l0-3: 0000000000000000 0000030ffffff220 0000000000000000 000000001044bdc0
+  %l4-7: 000000001044af18 00000300000043c0 000000001044f840 0000000000007fa3
+0000000010407230 genunix:kmem_cache_alloc+180 (0, 0, 0, 300000043c0, 0, 0)
+  %l0-3: 0000030000004740 ffffffffffffe000 000000001044ea18 0000000000002000
+  %l4-7: 0000030ffffff220 0000000000000000 0000000000002000 000000001044ea38
+00000000104072e0 genunix:kmem_slab_create+130 (200, 30000014000, 2000, 3000000da40, 0, 200)
+  %l0-3: 0000000000000000 ffffffffffffe000 000000001044ea18 0000000000002000
+  %l4-7: 0000030fffffef68 000003000000da40 0000000000002000 000000001044ea38
+00000000104073d0 genunix:kmem_cache_alloc+180 (0, 0, 0, 3000000da40, 0, 0)
+  %l0-3: 000003000000ddc0 0000000000000000 0000000000010000 ffffffffffffffff
+  %l4-7: 0000030000013fc8 00000300000052c0 0000030000013fc8 0000030000013fc0
+0000000010407480 genunix:kmem_alloc+2c (2000, 0, 2000, 3000000da40, 0, 30000013fb8)
+  %l0-3: 0000030000005640 0000000010147bfa 0000000000000000 0000000000000020
+  %l4-7: 0000000010446678 0000000010452543 0000000000000000 0000000000000000
+0000000010407530 krtld:kobj_zalloc+c (2000, 1000, 2000, 300000052c0, f0, 0)
+  %l0-3: 000003000000e740 ffffffffffffffc0 000000001044f8e0 00000000000003c0
+  %l4-7: 000000001044aa70 0000000000000000 0000000000000000 000000000000000b
+00000000104075e0 krtld:kobj_open_file+38 (2000, 30000011f88, 104397f0, 0, 0, 1)
+  %l0-3: 0000000000000008 0000000000000000 0000000000000000 0000000000000000
+  %l4-7: 0000000000000008 000000001004a3b4 0000000010452538 000000001004a438
+0000000010407690 genunix:mod_read_system_file+70 (10437c00, 2000, 1, 0, 26, 1043a0d8)
+  %l0-3: 0000000000004000 0000000000000008 0000000000004008 0000000000000000
+  %l4-7: 0000000000002000 000000001004a3b4 0000000010451670 000000001004a438
+00000000104077b0 genunix:kmem_init+1b8 (10471b50, 0, 0, 91, 1, 291)
+  %l0-3: 000000001041dc00 0000000000002000 000000001004a3b4 000000001004a438
+  %l4-7: 0000000010418590 0000000000001fff 000000001040d970 0000000000007fa3
+0000000010407880 unix:startup_memlist+b14 (10418400, 30000016080, 30000000000, 10418668, 2000, 30000016000)
+  %l0-3: 0000000000000103 0000000010423c00 0000000000000020 0000031002c00000
+  %l4-7: 0000000010418400 000000001041d000 000000001041c000 000000001041b000
+0000000010407970 unix:startup+c (10428c00, 0, 0, 1, 0, ffffffffffffffff)
+  %l0-3: 0000000010026090 000000000000d925 0000000000000afd 0000000000000000
+  %l4-7: 0000000010472880 00000000002e8c43 00000000000beafd 0000000000000afd
+0000000010407a20 genunix:main+4 (1040d400, 2000, 10407ec0, 10408030, fff2, 10052a0c)
+  %l0-3: 0000000010408000 0000000000000001 0000000000000015 0000000000000f36
+  %l4-7: 0000000010429618 0000000010472880 00000000000d7438 0000000000000540
+
+skipping system dump - no dump device configured
+rebooting...
+BOOTpanic - kernel: prom_reboot: reboot call returned!
+EXIT
+
+I'm not sure, but I think changes in this issue https://bugs.launchpad.net/qemu/+bug/1892540 might fix this one as well.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1906905 b/results/classifier/gemma3:12b/boot/1906905
new file mode 100644
index 000000000..93aa78873
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1906905
@@ -0,0 +1,13 @@
+
+qemu-system-sparc stucked while booting using ss20_v2.25_rom 
+
+I cannot boot up OBP using the current (5.1) version of qemu with ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged.  However using the previous version from 2015 I can successfully both up the OBP. 
+
+qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic
+
+Power-ON Reset
+
+(*hang) 
+
+regards
+Yap KV
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1907953 b/results/classifier/gemma3:12b/boot/1907953
new file mode 100644
index 000000000..34297cd70
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1907953
@@ -0,0 +1,4 @@
+
+pkg install qemu-system-x86_64  não funciona qemu 5.2.0
+
+A qemu funcionava mais quando atualizei para 5.2.0 não iniciar o Windows só fica tela preta quero voltar para anterior mais não consigo
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1908416 b/results/classifier/gemma3:12b/boot/1908416
new file mode 100644
index 000000000..2b210ac2f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1908416
@@ -0,0 +1,14 @@
+
+qemu-system-aarch64 can't run Windows 10 for ARM version 2004
+
+Problem: qemu-system-aarch64 can't run Windows 10 for ARM version 2004 (20H2) or newer
+
+Host OS: Windows 10 x64 version 20H2
+CPU    : Intel Pentium Dual-core T4300 (no vt-x)
+QEMU   : QEMU version 5.1.0 from qemu.org
+
+cmdline: qemu-system-aarch64.exe -M virt -cpu cortex-a72 -smp 3 --accel tcg,thread=multi -m 2048 -pflash QEMU_EFI.img -pflash QEMU_VARS.img -device VGA -device nec-usb-xhci -device usb-kbd -device usb-mouse -device usb-storage,drive=cdrom -drive file="isofile.iso",media=cdrom,if=none,id=cdrom
+
+Note: QEMU_VARS and QEMU_EFI are taken from edk2, which can be seen in the attachment below.
+
+Details: From this post (https://kitsunemimi.pw/notes/posts/running-windows-10-for-arm64-in-a-qemu-virtual-machine.html) and from what I have tried, QEMU can't run Windows ARM newer or equal to the 2004 version. When we boot a 2004 iso (made from uupdump.ml), it stuck as the boot screen with the Windows ARM logo and nothing else. When I check the machine state and registers through the QEMU monitor, it shows that the VM is still running, but the registers are completely frozen! But if I try the older version, like 19H2, it works! Please help!
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1915027 b/results/classifier/gemma3:12b/boot/1915027
new file mode 100644
index 000000000..852fe347a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1915027
@@ -0,0 +1,10 @@
+
+RISC-V 64, CPUs do ilegal 0x00 write with SMP
+
+When QEMU is runt like this:
+
+qemu-system-riscv64 -d unimp,guest_errors -smp 8
+
+Other harts will do a illegal write on address 0x00.
+
+This could be mostly (i think) because the initial assembly code is only loaded on the first hart and the others do a mess because there is no code to execute.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1915063 b/results/classifier/gemma3:12b/boot/1915063
new file mode 100644
index 000000000..fddaecb75
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1915063
@@ -0,0 +1,15 @@
+
+Windows 10 wil not install using qemu-system-x86_64
+
+Steps to reproduce
+install virt-manager and ovmf if nopt already there
+copy windows and virtio iso files to /var/lib/libvirt/images
+
+Use virt-manager from local machine to create your VMs with the disk, CPUs and memory required
+    Select customize configuration then select OVMF(UEFI) instead of seabios
+    set first CDROM to the windows installation iso (enable in boot options)
+    add a second CDROM and load with the virtio iso
+	change spice display to VNC
+
+  Always get a security error from windows and it fails to launch the installer (works on RHEL and Fedora)
+I tried updating the qemu version from Focals 4.2 to Groovy 5.0 which was of no help
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1915794 b/results/classifier/gemma3:12b/boot/1915794
new file mode 100644
index 000000000..251f6c051
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1915794
@@ -0,0 +1,11 @@
+
+could not load PC BIOS 'bios-256k.bin' on latest Windows exe (*-20210203.exe)
+
+I'm using https://scoop.sh/ to install QEMU on a Windows CI job, which is run daily. Since today, the job is failing with an `could not load PC BIOS 'bios-256k.bin'` error thrown by QEMU.
+
+The version that causes this error is: https://qemu.weilnetz.de/w64/2021/qemu-w64-setup-20210203.exe#/dl.7z
+The previous version, which worked fine, was: https://qemu.weilnetz.de/w64/2020/qemu-w64-setup-20201124.exe#/dl.7z
+
+Both CI runs build the exact same code. You can find the full logs at https://github.com/rust-osdev/x86_64/runs/1908137213?check_suite_focus=true (failing) and https://github.com/rust-osdev/x86_64/runs/1900698412?check_suite_focus=true (previous).
+
+(I hope this is the right place to report this issue.)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1917565 b/results/classifier/gemma3:12b/boot/1917565
new file mode 100644
index 000000000..b25486ab3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1917565
@@ -0,0 +1,31 @@
+
+Windows 10 fails with "Boot device inaccessible"
+
+The issue is happening on all versions I tried after the following commit. 
+
+git diff af1b80ae56c9495999e8ccf7b70ef894378de642~ af1b80ae56c9495999e8ccf7b70ef894378de642
+diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
+index b7bcbbbb2a..7a5a8b3521 100644
+--- a/hw/i386/acpi-build.c
++++ b/hw/i386/acpi-build.c
+@@ -1497,7 +1497,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
+         dev = aml_device("PCI0");
+         aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A03")));
+         aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
+-        aml_append(dev, aml_name_decl("_UID", aml_int(1)));
++        aml_append(dev, aml_name_decl("_UID", aml_int(0)));
+         aml_append(sb_scope, dev);
+         aml_append(dsdt, sb_scope);
+ 
+@@ -1512,7 +1512,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
+         aml_append(dev, aml_name_decl("_HID", aml_eisaid("PNP0A08")));
+         aml_append(dev, aml_name_decl("_CID", aml_eisaid("PNP0A03")));
+         aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
+-        aml_append(dev, aml_name_decl("_UID", aml_int(1)));
++        aml_append(dev, aml_name_decl("_UID", aml_int(0)));
+         aml_append(dev, build_q35_osc_method());
+         aml_append(sb_scope, dev);
+         aml_append(dsdt, sb_scope);
+
+The virtual machine start command:
+x86_64-softmmu/qemu-system-x86_64 -name guest=win10-dev,debug-threads=on -blockdev '{"driver":"file","filename":"/usr/share/OVMF/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' -blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/win10-dev_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' -blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' -machine pc-q35-4.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format -cpu Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff -m 6144 -overcommit mem-lock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 5646e540-5022-4ace-8d6a-d7c4b61a6d3d -no-user-config -nodefaults -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -blockdev '{"driver":"host_device","filename":"/dev/disk/by-id/scsi-1SanDisk_Extreme_SSD_20072F404043","aio":"native","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' -blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' -device ide-hd,bus=ide.0,drive=libvirt-2-format,id=sata0-0-0,bootindex=1,write-cache=on -device ide-cd,bus=ide.1,id=sata0-0-1 -netdev user,id=hostnet0 -device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:10:5b:55,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=5900,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.4,addr=0x0 -msg timestamp=on -D ./log.txt -monitor stdio -d
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1917940 b/results/classifier/gemma3:12b/boot/1917940
new file mode 100644
index 000000000..d85dd4ca6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1917940
@@ -0,0 +1,6 @@
+
+-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.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1919 b/results/classifier/gemma3:12b/boot/1919
new file mode 100644
index 000000000..ee1b5c7a9
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1919
@@ -0,0 +1,21 @@
+
+UEFI SecureCode hangs on MacOs - 8.1.1 / MacOS Ventura
+Description of problem:
+Unable to load edk2 secure boot UEFI code. Non-secure edk2 bios works fine, but secure one hangs during load.
+Steps to reproduce:
+1. Run mentioned command - it should display OVMF logo - but it hangs
+Additional information:
+* edk2-x86_64-code.fd works fine, edk2-x86_64-secure-code.fd not
+* Tested with swtpm and without - doesn't matter
+* TPM access has been observed (when swtpm enabled) - sounds like secure-code validation partially works
+
+To enable TPM:
+```
+   -chardev socket,id=chrtpm,path=mytpm0/swtpm-sock \
+   -tpmdev emulator,id=tpm0,chardev=chrtpm \
+   -device tpm-tis,tpmdev=tpm0 \
+```
+and run swtpm
+```
+swtpm socket --tpm2 --tpmstate dir=mytpm0 --ctrl type=unixio,path=mytpm0/swtpm-sock
+```
diff --git a/results/classifier/gemma3:12b/boot/192 b/results/classifier/gemma3:12b/boot/192
new file mode 100644
index 000000000..498af7490
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/192
@@ -0,0 +1,2 @@
+
+xv6 Bootloop
diff --git a/results/classifier/gemma3:12b/boot/1921280 b/results/classifier/gemma3:12b/boot/1921280
new file mode 100644
index 000000000..7780f5b42
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1921280
@@ -0,0 +1,8 @@
+
+OpenIndiana stuck in boot loop when using hvf
+
+I'm using QEMU version 5.2.0 on macOS, and running the "OpenIndiana Hipster 2020.10 Text Install DVD (64-bit x86)" ISO:
+
+qemu-system-x86_64 -cdrom ~/Downloads/OI-hipster-text-20201031.iso -m 2048 -accel hvf -cpu host
+
+It gets to "Booting...", stays there for a bit, and then restarts.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1921468 b/results/classifier/gemma3:12b/boot/1921468
new file mode 100644
index 000000000..a7dad8fbc
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1921468
@@ -0,0 +1,47 @@
+
+[UBUNTU 20.04] KVM guest fails to find zipl boot menu index
+
+---Problem Description---
+A KVM guest fails to find the zipl boot menu index if the "zIPL" magic value is listed at the end of a disk block. 
+ 
+---System Hang---
+System sits in disabled wait, last console display
+LOADPARM=[        ]
+Using virtio-blk.
+Using ECKD scheme (block size  4096), CDL
+VOLSER=[0X0067]
+ 
+ 
+---Steps to Reproduce---
+1. Install Distro KVM guest from ISO on a DASD, e.g. using virt-install, my invocation was 
+$ virt-install --name secguest2 --memory 2048 --disk path=/dev/disk/by-path/ccw-0.0.af6a --cdrom /var/lib/libvirt/images/xxxxxx.iso
+
+2. Select DHCP networking and ASCII console, and accept all defaults of the installer
+
+3. Let the installer reboot after the installation completes
+
+It is possible to recover by editing the domain XML with an explicit loadparm to select a boot menu entry. E.g. I changed the disk definition to
+   <disk type='block' device='disk'>
+      <driver name='qemu' type='raw' cache='none' io='native'/>
+      <source dev='/dev/disk/by-path/ccw-0.0.af6a'/>
+      <target dev='vda' bus='virtio'/>
+      <boot order='1' loadparm='1'/>
+      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0xaf6a'/>
+    </disk>
+
+The patches are now upstream:
+5f97ba0c74cc ("pc-bios/s390-ccw: fix off-by-one error")
+468184ec9024 ("pc-bios/s390-ccw: break loop if a null block number is reached")
+
+Current versions of qemu within Ubuntu
+
+focal (20.04LTS) 1:4.2-3ubuntu6 [ports]: arm64 armhf ppc64el s390x
+focal-updates (metapackages): 1:4.2-3ubuntu6.14: amd64 arm64 armhf ppc64el s390x
+
+groovy (20.10) (metapackages): 1:5.0-5ubuntu9 [ports]: arm64 armhf ppc64el s390x
+groovy-updates (metapackages): 1:5.0-5ubuntu9.6: amd64 arm64 armhf ppc64el s390x
+
+hirsute (metapackages): 1:5.2+dfsg-9ubuntu1: amd64 arm64 armhf ppc64el s390x 
+
+
+git-commits will apply seamlessley for the requested levels if not already integrated
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1923497 b/results/classifier/gemma3:12b/boot/1923497
new file mode 100644
index 000000000..4f427def1
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1923497
@@ -0,0 +1,28 @@
+
+bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed
+
+Trying boot/start a Windows 10 VM.  Worked until recently when this error started showing up.
+
+I have the following installed on Fedora 33:
+qemu-kvm-5.1.0-9.fc33.x86_64
+
+This is the error:
+
+Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: /builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239: bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed.
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, 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 1329, in startup
+    self._backend.create()
+  File "/usr/lib64/python3.9/site-packages/libvirt.py", line 1234, in create
+    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
+libvirt.libvirtError: internal error: process exited while connecting to monitor: qemu-system-x86_64: /builddir/build/BUILD/qemu-5.1.0/hw/acpi/bios-linker-loader.c:239: bios_linker_loader_add_checksum: Assertion `start_offset < file->blob->len' failed.
+
+I see this were referenced in a patch from some time ago and supposedly fixed.  Here is the patch info I was able to find:
+
+http://next.<email address hidden><email address hidden>/
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1925417 b/results/classifier/gemma3:12b/boot/1925417
new file mode 100644
index 000000000..ee2410b2c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1925417
@@ -0,0 +1,69 @@
+
+Cannot boot from EFI image on aarch64
+
+I am unable to boot from a EFI disk image on aarch64 qemu.
+
+I have qemu built and installed from sources on a jetson-nano
+
+qemu-system-aarch64 -version
+QEMU emulator version 5.2.50 (v5.2.0-3234-gbdee969c0e)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+
+KVM and and virtio are enabled in host kernel. 
+
+Now I want to boot a ChromiumOS image. I have the image downloaded from here:
+
+https://chromium.arnoldthebat.co.uk/?dir=daily
+
+The image looks fine:
+
+rreddy78@jetson-nano:~/Downloads$ fdisk -lu chromiumos_image.bin 
+Disk chromiumos_image.bin: 6.2 GiB, 6606109184 bytes, 12902557 sectors
+Units: sectors of 1 * 512 = 512 bytes
+Sector size (logical/physical): 512 bytes / 512 bytes
+I/O size (minimum/optimal): 512 bytes / 512 bytes
+Disklabel type: gpt
+Disk identifier: C5B6CA94-0AF1-374E-90B5-A5CF4DC1FF51
+
+Device                   Start      End Sectors  Size Type
+chromiumos_image.bin1  4513792 12902508 8388717    4G Linux filesystem
+chromiumos_image.bin2    20480    53247   32768   16M ChromeOS kernel
+chromiumos_image.bin3   319488  4513791 4194304    2G ChromeOS root fs
+chromiumos_image.bin4    53248    86015   32768   16M ChromeOS kernel
+chromiumos_image.bin5   315392   319487    4096    2M ChromeOS root fs
+chromiumos_image.bin6    16448    16448       1  512B ChromeOS kernel
+chromiumos_image.bin7    16449    16449       1  512B ChromeOS root fs
+chromiumos_image.bin8    86016   118783   32768   16M Linux filesystem
+chromiumos_image.bin9    16450    16450       1  512B ChromeOS reserved
+chromiumos_image.bin10   16451    16451       1  512B ChromeOS reserved
+chromiumos_image.bin11      64    16447   16384    8M unknown
+chromiumos_image.bin12  249856   315391   65536   32M EFI System
+
+Partition table entries are not in disk order.
+
+Now I try booting like this:
+
+qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu host -enable-kvm  \
+-device usb-ehci -device usb-kbd  -device usb-mouse -usb -serial stdio  \
+-device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \
+-device virtio-blk-device,drive=hd \
+-drive if=none,file=chromiumos_image.bin,format=raw,id=hd   \
+-netdev user,id=mynet   \
+-device virtio-net-device,netdev=mynet \
+-bios edk2-aarch64-code.fd -no-reboot
+
+But I am unable to boot.
+
+Memory Type Information settings change.
+[Bds]Booting UEFI Misc Device
+ BlockSize : 262144 
+ LastBlock : FF 
+[Bds] Expand VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00) -> <null string>
+BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found
+
+
+and 
+
+
+[Bds] Expand VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000) -> <null string>
+BdsDxe: failed to load Boot0002 "UEFI Misc Device 2" from VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A00000000): Not Found
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1926052 b/results/classifier/gemma3:12b/boot/1926052
new file mode 100644
index 000000000..203b38b98
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1926052
@@ -0,0 +1,16 @@
+
+qemu freezes during grub on arch cloudimg 
+
+When booting the Arch Linux cloud image and setting `-nographic`, qemu will freeze during the grub bootloader.
+Tested with qemu 5.1 and 5.2.
+
+Reproduce:
+```
+wget https://gitlab.archlinux.org/archlinux/arch-boxes/-/jobs/20342/artifacts/raw/output/Arch-Linux-x86_64-basic-20210420.20342.qcow2
+
+qemu-system-x86_64 -hda Arch-Linux-x86_64-basic-20210420.20342.qcow2 -nographic
+
+```
+
+It will get stuck while displaying `Welcome to GRUB!`
+If -nographic is omitted, it will continue to boot (without any keyboard interaction)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1952448 b/results/classifier/gemma3:12b/boot/1952448
new file mode 100644
index 000000000..597e17a75
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1952448
@@ -0,0 +1,24 @@
+
+qemu 1:6.0+dfsg-2expubuntu2: Fail to build against OpenSSL 3.0
+
+Issue discovered after doing a "No-change rebuild" upload to Jammy while working at the liburing2 migration (LP: #1944037). 
+
+Full build log:
+
+https://launchpadlibrarian.net/570888790/buildlog_ubuntu-jammy-amd64.qemu_1%3A6.0+dfsg-2expubuntu3_BUILDING.txt.gz
+
+Failure mode:
+
+/<<BUILDDIR>>/qemu-6.0+dfsg/roms/skiboot/libstb/create-container.c: In function ‘getPublicKeyRaw’:
+/<<BUILDDIR>>/qemu-6.0+dfsg/roms/skiboot/libstb/create-container.c:85:17: error: ‘EVP_PKEY_get1_EC_KEY’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
+
+Also note that:
+
+cc1: all warnings being treated as errors
+
+Upstream skiboot [1] still uses EVP_PKEY_get1_EC_KEY in master, and don't have an open issue about this. To be filed once we setup a reproducer that builds skiboot "standalone", outside of the qemu source tree.
+
+For the moment we have to relax the severity of that deprecation error, likely appending a -Wno-deprecated-declarations somewhere in d/rules.
+
+
+[1] https://github.com/open-power/skiboot
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/1995 b/results/classifier/gemma3:12b/boot/1995
new file mode 100644
index 000000000..d4298b3ef
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/1995
@@ -0,0 +1,2 @@
+
+No equivalent of `-boot once` for `bootindex`
diff --git a/results/classifier/gemma3:12b/boot/2010 b/results/classifier/gemma3:12b/boot/2010
new file mode 100644
index 000000000..2eb3634db
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2010
@@ -0,0 +1,81 @@
+
+The avocado test replay_kernel.py:ReplayKernelNormal.test_x86_64_pc is unreliable
+Description of problem:
+The replay test case is unreliable and often hangs at the second stage
+Additional information:
+The record stage complete fine:
+
+```
+2023-11-30 17:25:27,944 protocol         L0481 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'.
+2023-11-30 17:25:27,944 machine          L0925 DEBUG| Opening console file
+2023-11-30 17:25:27,944 machine          L0903 DEBUG| Opening console socket
+2023-11-30 17:25:42,652 __init__         L0153 DEBUG| [    0.000000] Linux version 4.18.16-300.fc29.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 8.2.1 20
+180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:24:08 UTC 2018
+2023-11-30 17:25:42,652 __init__         L0153 DEBUG| [    0.000000] Command line: printk.time=1 panic=-1 console=ttyS0
+2023-11-30 17:25:42,652 __init__         L0153 DEBUG| [    0.000000] x86/fpu: x87 FPU will use FXSAVE
+2023-11-30 17:25:42,652 __init__         L0153 DEBUG| [    0.000000] BIOS-provided physical RAM map:
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000007fdffff] usable
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x0000000007fe0000-0x0000000007ffffff] reserved
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x000000fd00000000-0x000000ffffffffff] reserved
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] NX (Execute Disable) protection: active
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] SMBIOS 3.0.0 present.
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/201
+4
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] last_pfn = 0x7fe0 max_arch_pfn = 0x400000000
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
+2023-11-30 17:25:42,653 __init__         L0153 DEBUG| [    0.000000] found SMP MP-table at [mem 0x000f5480-0x000f548f] mapped at [(____ptrval____)]
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: Early table checksum verification disabled
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: RSDP 0x00000000000F52A0 000014 (v00 BOCHS )
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: RSDT 0x0000000007FE1C78 000034 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: FACP 0x0000000007FE1B2C 000074 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: DSDT 0x0000000007FE0040 001AEC (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: FACS 0x0000000007FE0000 000040
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: APIC 0x0000000007FE1BA0 000078 (v03 BOCHS  BXPC     00000001 BXPC 00000001)
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: HPET 0x0000000007FE1C18 000038 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] ACPI: WAET 0x0000000007FE1C50 000028 (v01 BOCHS  BXPC     00000001 BXPC 00000001)
+2023-11-30 17:25:42,654 __init__         L0153 DEBUG| [    0.000000] No NUMA configuration found
+...
+```
+
+After recording the initial step the replay hangs shortly after mapping the BIOS until the test timeout terminates it.
+
+```
+2023-11-30 17:25:59,414 __init__         L0153 DEBUG| [    0.000000] Linux version 4.18.16-300.fc29.x86_64 (mockbuild@bkernel04.phx2.fedoraproject.org) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:24:08 UTC 2018
+2023-11-30 17:25:59,415 __init__         L0153 DEBUG| [    0.000000] Command line: printk.time=1 panic=-1 console=ttyS0
+2023-11-30 17:25:59,415 __init__         L0153 DEBUG| [    0.000000] x86/fpu: x87 FPU will use FXSAVE
+2023-11-30 17:25:59,415 __init__         L0153 DEBUG| [    0.000000] BIOS-provided physical RAM map:
+2023-11-30 17:25:59,416 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
+2023-11-30 17:25:59,416 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
+2023-11-30 17:25:59,420 __init__         L0153 DEBUG| [    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] re
+2023-11-30 17:27:28,826 stacktrace       L0039 ERROR| 
+2023-11-30 17:27:28,826 stacktrace       L0041 ERROR| Reproduced traceback from: /home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/core/test.py:770
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR| Traceback (most recent call last):
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/core/decorators.py", line 90, in wrapper
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     return function(obj, *args, **kwargs)
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 101, in test_x86_64_pc
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     self.run_rr(kernel_path, kernel_command_line, console_pattern, shift=5)
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 78, in run_rr
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     t2 = self.run_vm(kernel_path, kernel_command_line, console_pattern,
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/replay_kernel.py", line 61, in run_vm
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     self.wait_for_console_pattern(console_pattern, vm)
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/boot_linux_console.py", line 52, in wait_for_console_pattern
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     wait_for_console_pattern(self, success_message,
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/avocado_qemu/__init__.py", line 199, in wait_for_console_pattern
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     _console_interaction(test, success_message, failure_message, None, vm=vm)
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/home/alex/lsrc/qemu.git/builds/all/tests/avocado/avocado_qemu/__init__.py", line 148, in _console_interaction
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     msg = console.readline().decode().strip()
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|           ^^^^^^^^^^^^^^^^^^
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/usr/lib/python3.11/socket.py", line 706, in readinto
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     return self._sock.recv_into(b)
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|            ^^^^^^^^^^^^^^^^^^^^^^^
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|   File "/home/alex/lsrc/qemu.git/builds/all/pyvenv/lib/python3.11/site-packages/avocado/plugins/runner.py", line 77, in sigterm_handler
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR|     raise RuntimeError("Test interrupted by SIGTERM")
+2023-11-30 17:27:28,827 stacktrace       L0045 ERROR| RuntimeError: Test interrupted by SIGTERM
+2023-11-30 17:27:28,827 stacktrace       L0046 ERROR| 
+```
diff --git a/results/classifier/gemma3:12b/boot/2012 b/results/classifier/gemma3:12b/boot/2012
new file mode 100644
index 000000000..92ac9f9aa
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2012
@@ -0,0 +1,13 @@
+
+Possible regression: Windows 95 setup fails on show of license
+Description of problem:
+Install of Windows 95 fails when showing the license. Qemu v8.1.0 is fine, Qemu 8.1.3 and later failes. Git bisect suggest the problem may have been introduced at 9fb45b05582438dcd52d2d48d48feb05de680c37
+Steps to reproduce:
+1. Find install CD for Windows 95 and a DOS boot floppy
+2. Create a harddrive (size 300MB)
+3. Boot from floppy, create and format partition C: using all available space
+4. change to the CD at D: and run command SETUP.EXE
+5. follow instructions until display of license
+6. See error: SUWIN caused a General Protection Fault in module <unknown>
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/2015 b/results/classifier/gemma3:12b/boot/2015
new file mode 100644
index 000000000..0799a50c1
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2015
@@ -0,0 +1,28 @@
+
+qemu-system-sparc fails to boot Solaris 8 in an emulated SS-5
+Description of problem:
+Sun PROM fails to boot Solaris 8 in an emulated Sparcstation 5, with qemu exiting with a `trap 0x29` error.
+Steps to reproduce:
+1. Launch qemu with command line above
+2. Sun PROM tries to boot from the network and shows `Tiemout waiting for ARP/RARP packet` messages
+3. Interrupt network boot entering `sendkey stop-a` in qemu monitor (`compat_monitor0`)
+4. Back in Sun PROM, boot from cdrom: `boot cdrom:d`
+5. Solaris 8 starts booting
+6. qemu exits with fatal error
+
+```plaintext
+qemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state
+pc: f0041298  npc: f004129c
+%g0-7: 00000000 f02441a8 04400fc2 000001e2 00000027 f0243b88 00000000 f0244020
+%o0-7: ffff8000 00008000 00000f00 044000c1 f0258518 ffeec000 fbe3a4b8 f0041be4
+%l0-7: 04400fc1 f0041c78 f0041c7c 00000002 0000010f 00000002 0000002a fbe39f78
+%i0-7: ffff8000 00008000 00000f00 044000c2 00000000 ffeec000 fbe3a020 f0041be4
+%f00:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f08:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f16:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f24:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002
+fsr: 00000000 y: 00000000
+```
+Additional information:
+![Boot.png](/uploads/b83fe980b5baa1f0103fccc0abb6ec6c/Boot.png)
diff --git a/results/classifier/gemma3:12b/boot/2017 b/results/classifier/gemma3:12b/boot/2017
new file mode 100644
index 000000000..4dceda7e1
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2017
@@ -0,0 +1,18 @@
+
+Qemu 8.1-8.2 Sparc Now Timeout Boot Failing with Sun Bios
+Description of problem:
+Boot with original Sun bios never reaches the ok prompt.  You get a series of ongoing network boot attempts with the message "Timeout waiting for ARP/RARP package."
+
+On earlier versions of Qemu up to and including 8.0, you could use the original firmware in the combinations below on Sparc model SS-5 and SS-20 machines. 
+
+Note: Model SS-5 needs the cpu set to "TI MicroSparc II" or "TI MicroSparc IIep."  Model SS-20 needs the cpu set to "TI SuperSparc 50" or "TI SuperSparc 60."
+Steps to reproduce:
+1. Use Qemu 8.1, 8.2, or current
+2. Run above command line using original sun bios
+3. See result below
+
+![sun-obp-boot-error-timeout](/uploads/0b795b515108813528f6293b65f85c7a/sun-obp-boot-error-timeout.png)
+Additional information:
+Glad to test further and give checksums in bios files if needed.  Have real hardware for the Sparcstation 5.  Default lance card on qemu is active with usermode networking.
+
+Sun bios helps for booting some older versions of Solaris and is generally nice to have for testing.
diff --git a/results/classifier/gemma3:12b/boot/2036 b/results/classifier/gemma3:12b/boot/2036
new file mode 100644
index 000000000..c637aa5ac
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2036
@@ -0,0 +1,12 @@
+
+`edk2-riscv-code.fd.bz2` is included in the repo but not installed to `$PREFIX/share/qemu`
+Description of problem:
+`edk2-riscv-code.fd.bz2` is included in the repo (https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0-rc4/pc-bios/edk2-riscv-code.fd.bz2), but this file is not installed to `$PREFIX/share/qemu`.
+
+The binaries for other architectures (aarch64, arm, i386, x86\_64) are installed as expected.
+https://gitlab.com/qemu-project/qemu/-/blob/v8.2.0-rc4/pc-bios/meson.build?ref_type=tags#L3-L12
+Steps to reproduce:
+`ls $PREFIX/share/qemu/edk2-*`
+Additional information:
+- Not sure if this is intentional or a bug.
+- The descriptor JSON file is missing for riscv: https://gitlab.com/qemu-project/qemu/-/tree/v8.2.0-rc4/pc-bios/descriptors
diff --git a/results/classifier/gemma3:12b/boot/2044 b/results/classifier/gemma3:12b/boot/2044
new file mode 100644
index 000000000..d57546975
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2044
@@ -0,0 +1,6 @@
+
+HP-UX 10.20 doesn't boot on QEMU 8.2.0-rc4
+Description of problem:
+After update QEMU for v8.2.0-rc4 existing HP-UX 10.20 installation doesn't work anymore. I also tried to boot the installation media and SeaBIOS stays in loop.
+Additional information:
+#
diff --git a/results/classifier/gemma3:12b/boot/2070 b/results/classifier/gemma3:12b/boot/2070
new file mode 100644
index 000000000..d3df3c126
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2070
@@ -0,0 +1,10 @@
+
+TCG acceleration + EDK2  + Secure Boot hangs on boot since qemu 8.2
+Description of problem:
+Since qemu 8.2, using TCG acceleration in combination with EDK2-OVMF UEFI Secure Boot firmware hangs on boot. qemu freezes and keeps a full CPU core busy at 100% while it hangs. The issue does not occur when using KVM acceleration. It also does not occur when not using EDK2-OVMF UEFI firmware. It also does not occur when using the non secure boot EDK2-OVMF UEFI firmware.
+Steps to reproduce:
+1. `git clone https://github.com/systemd/mkosi`
+2. `cd mkosi`
+3. `bin/mkosi --tools-tree=default --tools-tree-distribution=arch --qemu-kvm=no --qemu-firmware=uefi --debug -f qemu`
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/2074 b/results/classifier/gemma3:12b/boot/2074
new file mode 100644
index 000000000..515f25713
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2074
@@ -0,0 +1,21 @@
+
+riscv64  cannot use the mret instruction to jump to the address corresponding to s mode
+Description of problem:
+I use coreboot to boot my linux kernel.The kernel is copied at 0x82200000,I set reg mepc 0x82200000,and set reg mstatus a00000800.
+and I use "mret" instruction so that qemu can jump to 0x82200000 and enter S mode.But some errors happened.
+It shows:
+[DEBUG]  Exception:          Instruction access fault
+[DEBUG]  Hart ID:            0
+[DEBUG]  Previous mode:      machine
+[DEBUG]  Bad instruction pc: 0x8103f7c0
+[DEBUG]  Bad address:        0x00000000
+[DEBUG]  Stored ra:          0x8103f7b8
+[DEBUG]  Stored sp:          0x82032f08
+Bad instruction pc: 0x8103f7c0 in my elf file instruction is "mret".
+So I can not jump to my kernel's load address.
+I think when I use -bios option,my qemu should in M mode.How could I can jump to my mepc address?
+Steps to reproduce:
+1.download qemu
+2.download coreboot
+Additional information:
+When I enter qemu with -bios option,I find that the reg mstatus is 0xa0000000.
diff --git a/results/classifier/gemma3:12b/boot/2090 b/results/classifier/gemma3:12b/boot/2090
new file mode 100644
index 000000000..65e212078
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2090
@@ -0,0 +1,8 @@
+
+Long initialisation of VM before boot.
+Description of problem:
+When i start VM in "Virtual machine manager" I got black screen, which hang there approximately one minute. After this delay VM begin booted and all work properly. Some time ago VMs booted immediately without mentioned delay after starting of VM. I checked all relevant log files, changed 3 times kernel, rebuilded Qemu, but problem persist. I don't know when problem began.
+
+![image.png](/uploads/1db2c4ebf070c71e3cd3838b13c0b190/image.png)
+
+##
diff --git a/results/classifier/gemma3:12b/boot/2091 b/results/classifier/gemma3:12b/boot/2091
new file mode 100644
index 000000000..11f17c35b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2091
@@ -0,0 +1,4 @@
+
+m68k: virt: Pass the configured cpu type via bootinfo instead of the default 68040
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/2092 b/results/classifier/gemma3:12b/boot/2092
new file mode 100644
index 000000000..e8fe939bc
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2092
@@ -0,0 +1,71 @@
+
+i386: TCG + virtiofs fails to boot Fedora/CentOS/OpenSUSE since QEMU v7.2
+Description of problem:
+When booting from virtiofs with TCG acceleration, after switch root from initramfs to rootfs, the system crashes horribly, see logs below. The failures only happen when TCG acceleration is used with a virtiofs rootfs. Switching TCG for KVM acceleration or virtiofs for a disk image makes the issue disappear. This has started happening since QEMU version 7.2. Using any qemu version before QEMU version 7.2 works fine. Additionally, it only seems to happen with CentOS Stream, Fedora and OpenSUSE. Using Debian, Ubuntu or Arch Linux, this combination boots fine.
+
+cc @bonzini since you made quite a few changes to TCG acceleration in QEMU v7.2.
+Steps to reproduce:
+1. `git clone https://github.com/systemd/mkosi`
+2. `cd mkosi`
+3. `bin/mkosi -d fedora -t directory --tools-tree=default --qemu-kvm=no --debug qemu` (this will build an image first so will take a while. Depending on your distribution you might need to install `dnf` and `bubblewrap`)
+Additional information:
+```
+<initramfs boot logs skipped for brevity>
+Welcome to Fedora Linux 39 (Thirty Nine)!
+
+[   37.137287] systemd[1]: Initializing machine ID from random generator.
+[   37.209193] kauditd_printk_skb: 9 callbacks suppressed
+[   37.209227] audit: type=1334 audit(1704961693.242:45): prog-id=16 op=LOAD
+[   37.210718] audit: type=1334 audit(1704961693.243:46): prog-id=16 op=UNLOAD
+[   37.211491] audit: type=1334 audit(1704961693.244:47): prog-id=17 op=LOAD
+[   37.212766] audit: type=1334 audit(1704961693.245:48): prog-id=17 op=UNLOAD
+[   37.241136] audit: type=1334 audit(1704961693.274:49): prog-id=18 op=LOAD
+[   37.242803] audit: type=1334 audit(1704961693.275:50): prog-id=18 op=UNLOAD
+[   37.244114] audit: type=1334 audit(1704961693.277:51): prog-id=19 op=LOAD
+[   37.245790] audit: type=1334 audit(1704961693.278:52): prog-id=19 op=UNLOAD
+[   37.259849] audit: type=1334 audit(1704961693.291:53): prog-id=20 op=LOAD
+[   37.260072] audit: type=1334 audit(1704961693.292:54): prog-id=20 op=UNLOAD
+[   37.870091] systemd[1]: bpf-lsm: BPF LSM hook not enabled in the kernel, BPF LSM not supported
+[   38.074465] Process 299(false) has RLIMIT_CORE set to 1
+[   38.074793] Aborting core
+[   38.077885] Process 297(false) has RLIMIT_CORE set to 1
+[   38.078066] Aborting core
+[   38.079360] Process 298(false) has RLIMIT_CORE set to 1
+[   38.079516] Aborting core
+[   38.114888] Process 301(false) has RLIMIT_CORE set to 1
+[   38.115072] Aborting core
+[   38.217830] Process 305(false) has RLIMIT_CORE set to 1
+[   38.218038] Aborting core
+[   38.219161] Process 304(false) has RLIMIT_CORE set to 1
+[   38.219337] Aborting core
+[   38.287937] Process 308(false) has RLIMIT_CORE set to 1
+[   38.288169] Aborting core
+[   38.323829] Process 309(false) has RLIMIT_CORE set to 1
+[   38.324045] Aborting core
+[   38.325457] Process 310(false) has RLIMIT_CORE set to 1
+[   38.325811] Aborting core
+[   38.447773] Process 315(false) has RLIMIT_CORE set to 1
+[   38.447934] Aborting core
+[   38.449525] Process 314(false) has RLIMIT_CORE set to 1
+[   38.449768] Aborting core
+[   38.462210] (sd-execu[291]: /usr/lib/systemd/system-generators/systemd-integritysetup-generator terminated by signal SEGV.
+[   38.478826] Process 316(false) has RLIMIT_CORE set to 1
+[   38.479001] Aborting core
+[   42.397416] systemd[1]: Populated /etc with preset unit settings.
+[   42.532156] show_signal_msg: 68 callbacks suppressed
+[   42.535164] systemd[1]: segfault at b0 ip 00007f3ca95074ed sp 00007ffc7aa5f1c0 error 4 in libsystemd-core-254.7-1.fc39.so[7f3ca944c000+135000] likely on CPU 0 (core 0, socket 0)
+[   42.536289] Code: 00 48 89 fb 75 6f c6 87 88 04 00 00 01 48 8b 7f 70 45 31 ed 48 85 ff 75 1e e9 7f 00 00 00 0f 1f 80 00 00 00 00 e8 f3 24 f5 ff <48> 8b 7b 70 41 83 c5 01 48 85 ff 74 66 f6 87 63 04 00 00 01 75 e5
+[   42.543019] systemd[1]: Caught <SEGV> from PID 176.
+[   42.543516] audit: type=1701 audit(1704961698.576:99): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=317 comm="systemd" exe="/usr/lib/systemd/systemd" sig=11 res=1
+[   42.593878] traps: false[318] general protection fault ip:7fcccd942fa0 sp:7ffd528a8020 error:0 in libc.so.6[7fcccd928000+160000]
+[   42.594494] Process 318(false) has RLIMIT_CORE set to 1
+[   42.594831] Aborting core
+[   42.595808] audit: type=1701 audit(1704961698.627:100): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=318 comm="false" exe="/usr/bin/false" sig=11 res=1
+[   42.603224] systemd[1]: Caught <SEGV>, dumped core as pid 317.
+[   42.604202] systemd[1]: Freezing execution.
+[   42.656248] audit: type=1335 audit(1704961698.689:101): pid=1 uid=0 auid=4294967295 tty=(none) ses=4294967295 comm="systemd" exe="/usr/lib/systemd/systemd" nl-mcgrp=1 op=disconnect res=1
+[   42.657685] audit: type=1334 audit(1704961698.690:102): prog-id=14 op=UNLOAD
+[   42.657852] audit: type=1334 audit(1704961698.690:103): prog-id=15 op=UNLOAD
+[   42.658011] audit: type=1334 audit(1704961698.690:104): prog-id=11 op=UNLOAD
+[   42.658201] audit: type=1334 audit(1704961698.690:105): prog-id=12 op=UNLOAD
+```
diff --git a/results/classifier/gemma3:12b/boot/2118 b/results/classifier/gemma3:12b/boot/2118
new file mode 100644
index 000000000..581e4f689
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2118
@@ -0,0 +1,2 @@
+
+make vm-build-openbsd reinstalls OpenBSD every time
diff --git a/results/classifier/gemma3:12b/boot/2129 b/results/classifier/gemma3:12b/boot/2129
new file mode 100644
index 000000000..f19ca8056
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2129
@@ -0,0 +1,2 @@
+
+migration-test sometimes fails
diff --git a/results/classifier/gemma3:12b/boot/2135 b/results/classifier/gemma3:12b/boot/2135
new file mode 100644
index 000000000..a8565a99a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2135
@@ -0,0 +1,25 @@
+
+Looking for ways to bypass MPS3-AN547 bootram size limit
+Description of problem:
+Could not boot MPS3-AN547 machine with images larger than 512KiB. 
+
+I've tried to move part of the symbols to other memory area, but the memories were discontinuous and this resulted in a large image which covers the reserved area in-between and wouldn't boot. I'm looking for advice on how to put more code in bootram. 
+
+I've also noticed the 8MB QSPI rom area, but AN547 does not have the remapping capability as AN524 and cannot use that as bootram. What is the best way to solve this?
+Steps to reproduce:
+1.Generate an image which goes beyond 0x00000000~(0+512K)
+
+2.```qemu-system-arm -M mps3-an547 -nographic -kernel big-image.bin```
+
+3."```qemu-system-arm: Could not load kernel 'nuttx/nuttx.bin'```"
+Additional information:
+Current working linker script:
+```
+MEMORY
+{
+  flash (rx)  : ORIGIN = 0x00000000, LENGTH = 512K
+  sram1 (rwx) : ORIGIN = 0x01000000, LENGTH = 2M
+  sram2 (rwx) : ORIGIN = 0x21000000, LENGTH = 4M
+}
+```
+Problem X is that the flash will overflow.
diff --git a/results/classifier/gemma3:12b/boot/2192 b/results/classifier/gemma3:12b/boot/2192
new file mode 100644
index 000000000..405f293cc
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2192
@@ -0,0 +1,2 @@
+
+make vm-build-openbsd tries to download nonexistent 7.2 install ISO: need to update to 7.4
diff --git a/results/classifier/gemma3:12b/boot/2194 b/results/classifier/gemma3:12b/boot/2194
new file mode 100644
index 000000000..2effa56c4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2194
@@ -0,0 +1,95 @@
+
+qemu-system-mips64el loongson3-virt fails to complete boot
+Description of problem:
+I try to install Debian 12 using the netboot kernel (6.1.0) and initrd:
+```
+NETBOOT=http://ftp.debian.org/debian/dists/stable/main/installer-mips64el/current/images/loongson-3/netboot
+wget $NETBOOT/initrd.gz
+wget $NETBOOT/vmlinuz-6.1.0-18-loongson-3 -O vmlinuz
+qemu-img create -f qcow2 disk.qcow2 30G
+```
+
+Then I boot the installer:
+```
+qemu-system-mips64el \
+     -machine loongson3-virt -cpu Loongson-3A1000 -smp 4 -m 6G -nographic \
+     -kernel vmlinuz -initrd initrd.gz \
+     -drive file=disk.qcow2,if=none,id=drive-virtio-disk0 \
+     -device virtio-blk-pci,drive=drive-virtio-disk0 \
+     -append "root=/dev/sda1"
+```
+
+The boot stops after this:
+```
+[    0.000000] Linux version 6.1.0-18-loongson-3 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 6.1.76-1 (2024-02-01)
+[    0.000000] Firmware: Coherent DMA: on
+[    0.000000] CpuClock = 800000000
+[    0.000000] The bridge chip is VIRTUAL
+[    0.000000] CP0_Config3: CP0 16.3 (0x80)
+[    0.000000] CP0_PageGrain: CP0 5.1 (0x20000000)
+[    0.000000] NUMA: Discovered 4 cpus on 1 nodes
+[    0.000000] Node 0, mem_type:1	[0x0000000000000000], 0x000000000f000000 bytes usable
+[    0.000000] Node 0, mem_type:2	[0x0000000090000000], 0x0000000170000000 bytes usable
+[    0.000000] Node0's addrspace_offset is 0x0
+[    0.000000] Node0: start_pfn=0x0, end_pfn=0x80000
+[    0.000000] NUMA: set cpumask cpu 0 on node 0
+[    0.000000] NUMA: set cpumask cpu 1 on node 0
+[    0.000000] NUMA: set cpumask cpu 2 on node 0
+[    0.000000] NUMA: set cpumask cpu 3 on node 0
+[    0.000000] printk: bootconsole [early0] enabled
+[    0.000000] CPU0 revision is: 00006305 (ICT Loongson-3)
+[    0.000000] FPU revision is: 00770501
+[    0.000000] MIPS: machine is loongson,loongson64v-4core-virtio
+[    0.000000] Initial ramdisk at: 0x9800000004000000 (28553950 bytes)
+[    0.000000] software IO TLB: area num 1.
+[    0.000000] software IO TLB: mapped [mem 0x0000000005b3c000-0x0000000009b3c000] (64MB)
+[    0.000000] DMI not present or invalid.
+[    0.000000] Detected 4 available CPU(s)
+[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
+[    0.000000] Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 32 bytes
+[    0.000000] Unified victim cache 0kB direct mapped, linesize 0 bytes.
+[    0.000000] Unified secondary cache 4096kB 4-way, linesize 32 bytes.
+[    0.000000] Zone ranges:
+[    0.000000]   DMA32    [mem 0x0000000000000000-0x00000000ffffffff]
+[    0.000000]   Normal   [mem 0x0000000100000000-0x00000001ffffffff]
+[    0.000000] Movable zone start for each node
+[    0.000000] Early memory node ranges
+[    0.000000]   node   0: [mem 0x0000000000000000-0x000000000effffff]
+[    0.000000]   node   0: [mem 0x0000000090000000-0x00000001ffffffff]
+[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000001ffffffff]
+[    0.000000] On node 0, zone DMA32: 1024 pages in unavailable ranges
+[    0.000000] percpu: Embedded 13 pages/cpu s170800 r8192 d34000 u212992
+[    0.000000] Fallback order for Node 0: 0 
+[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 390660
+[    0.000000] Policy zone: Normal
+[    0.000000] Kernel command line: rd_start=0xffffffff84000000 rd_size=28553950 root=/dev/sda1 nokaslr
+[    0.000000] Unknown kernel command line parameters "nokaslr", will be passed to user space.
+[    0.000000] Dentry cache hash table entries: 1048576 (order: 9, 8388608 bytes, linear)
+[    0.000000] Inode-cache hash table entries: 524288 (order: 8, 4194304 bytes, linear)
+[    0.000000] mem auto-init: stack:all(zero), heap alloc:on, heap free:off
+[    0.000000] Memory: 2183328K/6275072K available (11247K kernel code, 1773K rwdata, 3152K rodata, 2688K init, 547K bss, 184208K reserved, 0K cma-reserved)
+[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+[    0.000000] ftrace: allocating 32150 entries in 32 pages
+[    0.000000] ftrace: allocated 32 pages with 1 groups
+[    0.000000] trace event string verifier disabled
+[    0.000000] rcu: Preemptible hierarchical RCU implementation.
+[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4.
+[    0.000000] 	Trampoline variant of Tasks RCU enabled.
+[    0.000000] 	Rude variant of Tasks RCU enabled.
+[    0.000000] 	Tracing variant of Tasks RCU enabled.
+[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
+[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
+[    0.000000] NR_IRQS: 320
+[    0.000000] ISA Bridge: /bus@10000000/isa@18000000
+[    0.000000]  IO 0x0000000018000000..0x0000000018003fff  ->  0x0000000000000000
+[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
+[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 4778151116 ns
+[    0.000072] sched_clock: 32 bits at 400MHz, resolution 2ns, wraps every 5368709118ns
+[    0.002813] Console: colour dummy device 80x25
+[    0.003195] printk: console [tty0] enabled
+[    0.005876] printk: bootconsole [early0] disabled
+```
+
+Then, nothing happens. The qemu process uses 100% CPU on the host.
+
+I tried with `-smp 1` and got the same result.
diff --git a/results/classifier/gemma3:12b/boot/2199 b/results/classifier/gemma3:12b/boot/2199
new file mode 100644
index 000000000..ac0ccac9c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2199
@@ -0,0 +1,13 @@
+
+QEMU8 not working properly for Win9x guest
+Description of problem:
+Cannot boot to Win9x desktop. Enter safe mode of Win9x, then open C:\Windows\system\iosubsys, then rename drvwq117.vxd to drvwq117.vxd.bak, this problem solved.<br />
+Sound card and network card not found in Win9x Device Manager.<br />
+Cannot change resolution in Win9x Control Panel, this will cause "RUNDLL32 program error".
+
+We found that Plug-and-Play (\$PNP) and PCI IRQ Routing (\$PIR) functions of SeaBIOS are buggy for Win9x guest.
+Steps to reproduce:
+1.Install Win98 RTM on QEMU8, it cannot boot to Win98 desktop.<br />
+2.Install WinME on QEMU8, it will stuck on "copying files".
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/2204 b/results/classifier/gemma3:12b/boot/2204
new file mode 100644
index 000000000..bd3000679
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2204
@@ -0,0 +1,74 @@
+
+Hyper-V on Windows Server 2022 cannot load images converted from OVA to VHDX by qemu-img: Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device
+Description of problem:
+We have reference OVA image: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova and we want to convert it to VMDX format.
+Steps to reproduce:
+I downloaded reference OVA and converted it to VMDX with three possible options.
+
+With subformat dynamic:
+```
+qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=dynamic fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx
+```
+
+And without it:
+```
+qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx
+```
+
+And with explicitly setting fixed:
+```
+qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=fixed fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx
+```
+
+In all cases I tried loading images using VM of Generation 1 and Generation 2:
+```
+The application encountered an error while attempting to change the state of
+'New Virtual Machine'.
+
+'New Virtual Machine' failed to start.
+
+Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse..
+
+Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.hdx''. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse..
+
+Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.vhdx'. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.'.
+```
+
+I noticed some similarities with https://gitlab.com/qemu-project/qemu/-/issues/136 and applied workaround to fix it:
+```
+fsutil sparse setflag fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx 0
+``` 
+
+It started complaining that file is being used by another app. I waited long enough and then rebooted server. 
+
+After that error changed to:
+```
+Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device_
+```
+
+As image:
+
+![Screenshot_from_2024-03-02_21-15-10](/uploads/9e172b941d160d2538cf903c1249e9d8/Screenshot_from_2024-03-02_21-15-10.png)
+
+For Generation 2 error is slightly different:
+```
+Virtual Machine Boot Summary
+1. SCSI Disk
+(0,0)
+The boot loader did not load an operating system.
+2. Network Adapter (00155D01770C)
+A boot image was not found.
+```
+
+As image: ![Screenshot_from_2024-03-02_21-36-37](/uploads/d3bc3ac142096e0ef6fc25e91c299ebc/Screenshot_from_2024-03-02_21-36-37.png)
+
+I tried doing conversion from VirtualBox with same OVA and it worked just fine:
+```
+VBoxManage clonehd fastnetmon-ubuntu-22.04-amd64-disk1.vmdk fastnetmon.vhd --format vhd
+```
+
+I believe something is wrong with boot records for VMDX images.
+
+Example of converted VHDX with dynamic flag can be found here: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.356.0.vhdx 
+
+By Pavel Odintsov at FastNetMon.com
diff --git a/results/classifier/gemma3:12b/boot/2224 b/results/classifier/gemma3:12b/boot/2224
new file mode 100644
index 000000000..093302c7e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2224
@@ -0,0 +1,206 @@
+
+OpenBSD 7.4+ does not boot on sbsa-ref with Neoverse-V1/N2 or max cpu core
+Description of problem:
+System boots and then hangs:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1
+3d5cf8
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.4 (RAMDISK) #2131: Sun Oct  8 13:35:40 MDT 2023
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066156032 (1016MB)
+avail mem = 996659200 (950MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3
+cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache
+cpu0: 0KB 64b/line 8-way L2 cache
+cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+simplefb0 at mainbus0: 1280x800, 32bpp
+wsdisplay0 at simplefb0 mux 1
+wsdisplay0: screen 0 added (std, vt100 emulation)
+```
+
+If I use Neoverse-N1 (sbsa-ref default core type) then it boots into installer:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 2861736+1091248+12711584+634544 [233295+91+666048+260913]=0x1
+3d5cf8
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.4 (RAMDISK) #2131: Sun Oct  8 13:35:40 MDT 2023
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066156032 (1016MB)
+avail mem = 996659200 (950MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r4p1
+cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache
+cpu0: 1024KB 64b/line 8-way L2 cache
+cpu0: DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+simplefb0 at mainbus0: 1280x800, 32bpp
+wsdisplay0 at simplefb0 mux 1
+wsdisplay0: screen 0 added (std, vt100 emulation)
+softraid0 at root
+scsibus1 at softraid0: 256 targets
+root on rd0a swap on rd0b dump on rd0b
+WARNING: CHECK AND RESET THE DATE!
+erase ^?, werase ^W, kill ^U, intr ^C, status ^T
+
+Welcome to the OpenBSD/arm64 7.4 installation program.
+(I)nstall, (U)pgrade, (A)utoinstall or (S)hell?
+```
+Steps to reproduce:
+1. download OpenBSD 7.4 image: https://cdn.openbsd.org/pub/OpenBSD/7.4/arm64/miniroot74.img
+2. download sbsa-ref firmware files from https://artifacts.codelinaro.org/ui/native/linaro-419-sbsa-ref/20240313-116475/edk2/ and decompress them
+3. start qemu-system-aarch64 as shown above (adapt paths if needed)
+4. watch console serial output
+Additional information:
+I am going to discuss this on OpenBSD mailing list. Will point to this bug.
+
+OpenBSD 7.5-current snapshot works on Neoverse-N1 and fails on Neoverse-V1/N2/max:
+
+```
+disks: sd0*
+>> OpenBSD/arm64 BOOTAA64 1.18
+boot>
+cannot open sd0a:/etc/random.seed: No such file or directory
+booting sd0a:/bsd: 3015576+1213504+12712936+634144 [269381+91+701664+287051]=0x1
+3edee0
+FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+Copyright (c) 1982, 1986, 1989, 1991, 1993
+        The Regents of the University of California.  All rights reserved.
+Copyright (c) 1995-2024 OpenBSD. All rights reserved.  https://www.OpenBSD.org
+
+OpenBSD 7.5 (RAMDISK) #121: Thu Mar 14 03:28:46 MDT 2024
+    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/RAMDISK
+real mem  = 1066147840 (1016MB)
+avail mem = 992886784 (946MB)
+random: boothowto does not indicate good seed
+mainbus0 at root: ACPI
+psci0 at mainbus0: PSCI 1.1, SMCCC 1.4
+efi0 at mainbus0: UEFI 2.7
+efi0: EFI Development Kit II / SbsaQemu rev 0x10000
+smbios0 at efi0: SMBIOS 3.4.0
+smbios0: vendor EFI Development Kit II / SbsaQemu version "1.0" date 03/13/2024
+smbios0: QEMU QEMU SBSA-REF Machine
+cpu0 at mainbus0 mpidr 0: ARM Neoverse N2 r0p3
+cpu0: 0KB 64b/line 4-way L1 PIPT I-cache, 0KB 64b/line 4-way L1 D-cache
+cpu0: 0KB 64b/line 8-way L2 cache
+cpu0: RNDR,TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SM4,SM3,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPA,LRCPC+LDAPUR,FCMA,JSCVT,APA+PAC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2+SCXT,DIT,BT,SBSS+MSR,MTE
+agintc0 at mainbus0 shift 4:3 nirq 288 nredist 4: "interrupt-controller"
+agintcmsi0 at agintc0
+agtimer0 at mainbus0: 62500 kHz
+acpi0 at mainbus0: ACPI 6.0
+acpi0: tables DSDT FACP DBG2 MCFG SPCR IORT APIC SSDT PPTT GTDT BGRT
+acpimcfg0 at acpi0
+acpimcfg0: addr 0xf0000000, bus 0-255
+acpiiort0 at acpi0
+pluart0 at acpi0 COM0 addr 0x60000000/0x1000 irq 33
+pluart0: console
+ahci0 at acpi0 AHC0 addr 0x60100000/0x10000 irq 42: AHCI 1.0
+ahci0: port 0: 1.5Gb/s
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: <ATA, QEMU HARDDISK, 2.5+> t10.ATA_QEMU_HARDDISK_QM00001_
+sd0: 43MB, 512 bytes/sector, 88064 sectors, thin
+xhci0 at acpi0 USB0 addr 0x60110000/0x10000 irq 43, xHCI 0.0
+usb0 at xhci0: USB revision 3.0
+uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
+acpipci0 at acpi0 PCI0
+pci0 at acpipci0
+0:1:0: rom address conflict 0xfffc0000/0x40000
+0:2:0: rom address conflict 0xffff8000/0x8000
+"Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured
+em0 at pci0 dev 1 function 0 "Intel 82574L" rev 0x00: msi, address 52:54:00:12:34:56
+"Bochs VGA" rev 0x02 at pci0 dev 2 function 0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+"ACPI0007" at acpi0 not configured
+```
diff --git a/results/classifier/gemma3:12b/boot/2233 b/results/classifier/gemma3:12b/boot/2233
new file mode 100644
index 000000000..986865f5b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2233
@@ -0,0 +1,50 @@
+
+EDK2 BIOS images have wrong version string
+Description of problem:
+cosmetic, low priority, but maybe easy to fix  
+I think the displayed version inside the edk2 bios interface is not updating from version to version.  
+The updated version number is useful for the qemu-user to be assured that the updated bios file is in use.  
+
+There is also some unreliability in whether the bios screen is entered on pressing F2. I need to try do it a few times, that is restart qemu, for it to succeed and reach the bios interface. No issue with registering the F2 keystroke, starting screen does react to it. Sometimes it stops on a intermediate bios screen that does probing. I documented this as a different bug #2234 . 
+
+The reason I am trying out these bios files is because I am having trouble booting an iso image, which I filed as a different bug #2235. 
+
+This is how I create a bios file on update of a qemu version.   
+I have extracted and overwritten the 8.2.0 files in the scoop installed qemu folder with 9.0.0-rc0 files from gitlab artifact.   
+I have used ```qemu-setup-v9.0.0-rc0-42-g54294b23e1.exe``` which should include kraxel's 20240320 pull request ```[PULL 0/5] Edk2 20240320 patches Gerd Hoffmann```.  
+In a command prompt window   
+```C:\vol\scoop_01\scoopg\apps\qemu\8.2.0\share> C:\vol\scoop_01\scoopg\apps\git\current\usr\bin\cat.exe .\edk2-i386-vars.fd .\edk2-x86_64-code.fd > D:\vstorage\win_m01_qemu_2403_edk2-x86_64.fd```
+
+so far following files have been created
+```
+D:\vstorage>dir D:\vstorage\win_m01_qemu_2*
+ Volume in drive D is VD_15KJ
+ Volume Serial Number is 1EA6-2771
+
+ Directory of D:\vstorage
+
+04/17/2023  09:23 PM         4,194,304 win_m01_qemu_2302_edk2-x86_64.fd   # 8.0.0
+03/20/2024  10:31 AM         4,194,304 win_m01_qemu_2308_edk2-x86_64.fd   # 8.1.0
+03/20/2024  01:18 PM         4,194,304 win_m01_qemu_2402_edk2-x86_64.fd   # 8.2.0
+03/21/2024  11:24 AM         4,194,304 win_m01_qemu_2403_edk2-x86_64.fd   # 9.0.0-rc0
+               4 File(s)     16,777,216 bytes
+               0 Dir(s)  140,732,907,520 bytes free
+
+D:\vstorage>C:\vol\scoop_01\scoopg\apps\git\current\usr\bin\cmp.exe win_m01_qemu_2302_edk2-x86_64.fd win_m01_qemu_2403_edk2-x86_64.fd
+win_m01_qemu_2302_edk2-x86_64.fd win_m01_qemu_2403_edk2-x86_64.fd differ: char 540809, line 1
+
+D:\vstorage>C:\vol\scoop_01\scoopg\apps\git\current\usr\bin\cmp.exe win_m01_qemu_2402_edk2-x86_64.fd win_m01_qemu_2403_edk2-x86_64.fd
+D:\vstorage>
+```
+
+The above indicate to me that nothing has changed in edk2 binaries between 8.2.0 and 9.0.0. Is that correct?
+Steps to reproduce:
+1. start qemu
+2. press F2 when qemu guest display window pops up. When it works, it brings up the edk2 bios interface. 
+3. observe guest display screen . Notice that the displayed version still says `edk2-stable202302-for-qemu`. The displayed version has remained the same regardless of the bios file being used to boot qemu be they from 8.0.0 upto 9.0.0  
+   I expect it to show `edk2-stable202302-for-qemu`, `edk2-stable202308-for-qemu`, `edk2-stable202402-for-qemu`, `edk2-stable202403-for-qemu` etc
+
+guest display screen
+![QEMU_3_21_2024_11_25_00_AM](/uploads/3f7d55ff6e4dbd4a0bc00535027c0b2c/QEMU_3_21_2024_11_25_00_AM.png)
+Additional information:
+herein notifying @kraxel
diff --git a/results/classifier/gemma3:12b/boot/2235 b/results/classifier/gemma3:12b/boot/2235
new file mode 100644
index 000000000..9cb2e5869
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2235
@@ -0,0 +1,58 @@
+
+Hiren's Bootcd PE LiveCD not booting in windows qemu
+Description of problem:
+Hiren's Bootcd PE LiveCD not booting up in windows qemu.  
+PE stands for pre-execution environment which is like a minimal boot environment like windows-recovery.  
+The ram drive it makes is about 3.5 GiB.  
+Being able to boot something like Hiren BootCD PE is like a simple test of qemu.   
+
+I've tried many things, but I can't figure out if it's because I can't get the arguments right or if it is because of something else.
+ 
+So far, using windows-qemu, I have not tried to boot a win10-guest-OS on win10 host-OS.
+Steps to reproduce:
+1. Try to start qemu as per command. Try figure out what the right arguments/options are.
+
+The live cd boot process is as follows
+1. First the livecd bootloader loads files from the cdrom and unpacks them into a ramdrive
+   During this phase, in the taskmgr it can be seen that the memory of the qemu process grows to about 1.5 GiB
+2. Then the boot process should transfer to the unpacked OS in the ramdrive.  
+   In the center of the screen, if one is doing efi-boot, then one can see the tianocore logo, else if one is doing legacy boot, then one can see the windows logo.  
+   The windows loading animation, dots in circle, does not start. In some boot attempts, it seems to have put only 1 dot, in other boot attempts nothing at all.  
+   Even after the expansion phase, the qemu process in the taskmgr shows a 11% use (which 1 cpu in a hyperthreading i7 quadcore cpu).  
+   This means emulator is doing something. But, despite waiting for a long time, nothing seems to happen in the guest-display-window.  
+
+```
+PS F:\> dir D:\bootable\hb*.iso
+
+    Directory: D:\bootable
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           9/17/2021  7:29 PM     3099203584 HBCD_PE_x64_v1.0.2_20210701.iso
+-a---           3/13/2024  4:45 PM     3291686912 HBCD_PE_x64_v1.0.8_20240305.iso
+
+PS F:\> Get-FileHash -Algorithm SHA256 D:\bootable\HBCD_PE_x64_v1.0.2_20210701.iso
+
+Algorithm       Hash                                                                   Path
+---------       ----                                                                   ----
+SHA256          8281107683E81BE362AFD213026D05B2219BC6A7CA9AF4D2856663F3FFC17BFD       D:\bootable\HBCD_PE_x64_v1.0.2_…
+
+PS F:\> Get-FileHash -Algorithm SHA256 D:\bootable\HBCD_PE_x64_v1.0.8_20240305.iso
+
+Algorithm       Hash                                                                   Path
+---------       ----                                                                   ----
+SHA256          8C4C670C9C84D6C4B5A9C32E0AA5A55D8C23DE851D259207D54679EA774C2498       D:\bootable\HBCD_PE_x64_v1.0.8_…
+
+PS F:\> Get-Content D:\bootable\HBCD_PE_x64_v1.0.2_20210701.iso.sha256
+8281107683E81BE362AFD213026D05B2219BC6A7CA9AF4D2856663F3FFC17BFD  HBCD_PE_x64_v1.0.2_20210701.iso
+PS F:\> Get-Content D:\bootable\HBCD_PE_x64_v1.0.8_20240305.iso.sha256
+8c4c670c9c84d6c4b5a9c32e0aa5a55d8c23de851d259207d54679ea774c2498  HBCD_PE_x64_v1.0.8_20240305.iso
+```
+Additional information:
+- https://www.hirensbootcd.org/download/
+- method to create the bios file is explained in #2233 
+- I have booted into v1.0.2 in native, so I know v1.0.2 works.  
+- I have tried qemu with and without EFI bios. 
+- The more recent v1.0.8 released on 20240305 is Win11 PE based (>22621)
+- Virtualbox-7.0.14 is able to boot HBCDPE as normal, but with EFI disabled, and not when enabled.  
+- As of this issue creation, not yet checked whether under Linux if qemu-kvm can boot HBCDPE.
diff --git a/results/classifier/gemma3:12b/boot/236 b/results/classifier/gemma3:12b/boot/236
new file mode 100644
index 000000000..bbb84b258
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/236
@@ -0,0 +1,2 @@
+
+CPU fetch from unpopulated ROM on reset
diff --git a/results/classifier/gemma3:12b/boot/2361 b/results/classifier/gemma3:12b/boot/2361
new file mode 100644
index 000000000..dcbcd043c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2361
@@ -0,0 +1,14 @@
+
+-cpu host or -cpu max breaks GRUB on AMD
+Description of problem:
+I'm running the on an AMD Ryzen CPU host.  I am emulating a Debian Bookworm image stored in a raw disk.  It uses GRUB to load a large (400MB) initrd.  When ran with the flag -cpu host or -cpu max, GRUB throws an out of memory error while loading the initrd.  This doesn't occur when using -cpu kvm64 or excluding the -cpu flag.
+
+If I direct boot the initrd and kernel via -initrd and -kernel, it works fine.  The image also works with -cpu host on an Intel CPU host machine.  The image also works with -cpu EPYC.
+Steps to reproduce:
+1. Create a raw disk with a large initrd and GRUB boot loader
+2. Start a qemu machine on an AMD host 
+3. Receive an error: out of memory
+Additional information:
+I could try selectively enabling CPU features, but I was wondering if the maintainers knew of any feature that might be causing this or how to list the features -cpu host enables.
+
+I also am not 100% that this is a QEMU bug, but it seems the only way to fix it is changing the QEMU config.
diff --git a/results/classifier/gemma3:12b/boot/2365 b/results/classifier/gemma3:12b/boot/2365
new file mode 100644
index 000000000..bed0f8366
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2365
@@ -0,0 +1,9 @@
+
+[Regression v8.2/v9.0+] stuck at SeaBIOS for >30s with 100% CPU (1T)
+Description of problem:
+starting our Linux direct-kernel-boot VMs with same args on different hosts/hardware will get stuck at SeaBIOS for 30-60s with 100% 1T CPU load starting with v8.2 and also in v9.0. v9.0.0 and v8.2.3 - v8.1.5 is OK. To be clear, everything seems to be fine after that, though I did not do any benchmarks to compare performance. It just delays (re)booting by almost 1 minute, which is a shame, because before that update/regression it was instant and our VMs only take 4s to boot, which is now more like 60s.
+Downgrading to v8.1 instantly fixes it, upgrading to v8.2/v9.0 instantly breaks it.
+Steps to reproduce:
+1. start VM with same args on different versions
+
+somehow if I save this bug with `/label ~"kind::Bug"` it disappears, so I'm unable to add/keep the label
diff --git a/results/classifier/gemma3:12b/boot/2393 b/results/classifier/gemma3:12b/boot/2393
new file mode 100644
index 000000000..155877fd3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2393
@@ -0,0 +1,21 @@
+
+qemu: seabios hangs for 10~15 sec at boot with `-machine q35`
+Description of problem:
+Whenever i'm starting a virtual machine i'm having the issue that seabios (or at least that's what i see) hangs for about 10~15 seconds. In that time on of the cpu cores runs at 100%.
+This issue isn't new actually. I'm having this already for quite some time and a i think for at least the last 2 major versions. I haven't looked into it since it isn't a big issue, just annoying.
+Today i've looked into it and as far as i can see, this issue is always present with the flag `-machine q35`, which is the default for my vm's. If i set it to `-machine pc`, booting works as expected. However i also found a "workaround" where the vm's starting immediately (with `-machine q35` enabled), which is by simply adding a iso image to the command line (via -cdrom) - even though it's not used.
+
+This means:
+- 15 sec delay: qemu-system-x86_64 -machine q35
+- works immediately: qemu-system-x86_64 -machine q35 -cdrom /mnt/data/vm/isos/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230303-Media.iso
+
+Please note that most of my vm's usually start booting from a kernel image directly (-kernel /mnt/data/vm/kernel/gentoo-latest -initrd /mnt/data/vm/kernel/initrd-v5.cpio.gz) - but even in that case settings a cdrom (image) would fix the issue.
+Also, the image needs to be a valid one, if i set an empty file or /dev/null the issue would remain.
+Further more, i have the same issue on a second computer. This also runs on Gentoo Linux and is also a AMD Ryzen. (in case this is relevant)
+Steps to reproduce:
+1. qemu-system-x86_64 -machine q35
+2. wait about 10-15sec before boot continues
+Additional information:
+I was thinking to add an Screenshot of the hanging boot process, but the only text written there is:
+SeaBIOS (version 1.16.0-20220807_005459-localhost)
+with a blinking cursor below
diff --git a/results/classifier/gemma3:12b/boot/2403 b/results/classifier/gemma3:12b/boot/2403
new file mode 100644
index 000000000..65d27ef94
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2403
@@ -0,0 +1,15 @@
+
+WHPX accelerator fails to boot guest Windows 7
+Description of problem:
+I get Qemu freezed on Starting Windows screen when trying to boot Windows 7 Professional
+Steps to reproduce:
+1. Run qemu with the above command line and until Starting Windows screen appears.
+2. See qemu freezed.
+Additional information:
+tcg accelerator works ok, though (Windows 7 successfully boots as expected on native hardware):
+
+- `qemu-system-x86_64.exe -accel tcg -cpu Westmere,aes=on,avx=on,sse4.1=on,sse4.2=on,ssse3=on,x2apic=on,xsave=on -m 4G -machine q35 -device qxl-vga,vgamem_mb=64 -hda Windows7_Disk.qcow2 -boot d -cdrom Windows7.iso`
+
+  This bug seems to have the same roots: https://gitlab.com/qemu-project/qemu/-/issues/1859
+
+  ![Capture.PNG](/uploads/f934e620a4b3c157fc34e8ff38470a0b/Capture.PNG){width=579 height=477}
diff --git a/results/classifier/gemma3:12b/boot/2421 b/results/classifier/gemma3:12b/boot/2421
new file mode 100644
index 000000000..37f57285e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2421
@@ -0,0 +1,19 @@
+
+Cannot boot ArcaOS 5.1.0 (a distro of OS/2 Warp 4.52) in UEFI mode
+Description of problem:
+ArcaOS has added the UEFI support since 5.1.0, it has been tested on my physical machine(Ryzen 3300X + RTX2060 Super), and VirtualBox with an `Other x64` machine(the new OS/2 bootloader used in UEFI mode is x64 only).
+
+Fixes applied to #2198 are perfectly worked in legacy BIOS mode, but if I tried to boot it in UEFI mode, it will stuck on logo screen, and if I enable verbose mode in boot menu, nothing will be shown on the screen and serial ports.
+
+It happens in both `i440fx` machine type and `q35` machine type.
+Steps to reproduce:
+1. Install latest qemu HEAD version via `brew install qemu --HEAD`
+2. Create new virtual disk via `qemu-img create -f qcow2 hdd.img 20G`
+3. Copy EFI bios file and var file
+   ```
+   cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-x86_64-code.fd bios.fd
+   cp /opt/homebrew/Cellar/qemu/HEAD-1a2d52c/share/qemu/edk2-i386-vars.fd vars.fd
+   ```
+4. Launch it
+Additional information:
+![截屏2024-07-03_17.33.19](/uploads/74723c79ae46a72d2fbf9d89194cbb3a/截屏2024-07-03_17.33.19.png)
diff --git a/results/classifier/gemma3:12b/boot/243 b/results/classifier/gemma3:12b/boot/243
new file mode 100644
index 000000000..245df003d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/243
@@ -0,0 +1,2 @@
+
+Qemu refuses to multiboot Elf64 kernels
diff --git a/results/classifier/gemma3:12b/boot/2453 b/results/classifier/gemma3:12b/boot/2453
new file mode 100644
index 000000000..863712a30
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2453
@@ -0,0 +1,10 @@
+
+qemu-system-rx aborts when trying to run the u-boot binary
+Description of problem:
+I tried to run the tests/avocado/machine_rx_gdbsim.py:RxGdbSimMachine.test_uboot test (which is not run by default since it is marked as flaky), but seems like QEMU now always aborts when trying to run with the u-boot bios.
+Steps to reproduce:
+1. wget https://acc.dl.osdn.jp/users/23/23888/u-boot.bin.gz
+2. gunzip u-boot.bin.gz
+3. qemu-system-rx -nographic -M gdbsim-r5f562n8 -bios u-boot.bin
+Additional information:
+Aborts with: ``qemu-system-rx: ../../devel/qemu/accel/tcg/translator.c:286: translator_ld: Assertion `((base ^ pc) & TARGET_PAGE_MASK) == 0' failed.``
diff --git a/results/classifier/gemma3:12b/boot/2464 b/results/classifier/gemma3:12b/boot/2464
new file mode 100644
index 000000000..1553595be
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2464
@@ -0,0 +1,12 @@
+
+"rc4030: invalid read at 0xf0-0xf8" shows up, then NT MIPS bluescreens
+Description of problem:
+The problem is fairly nondescript, but it seems to be a chipset regression that popped up between QEMU 8 and QEMU 9. I had a Windows NT 4 VM that I tried booting in the latest QEMU update after a while of not using it, and it just flat-out refused to do that, outputting the ``INACCESSIBLE_BOOT_DEVICE`` error. Any attempt to boot from the hard drive or reinstall the OS from the CD image would return the same bluescreen, and would show the very message shown in the title in the process log.
+Steps to reproduce:
+1. Download a Windows NT 3.5x/4.0 ISO.
+2. Create a disk image ≤2GB in size.
+3. Enter the command above.
+4. Go through the preparatory setup, as described in [here](https://computernewb.com/wiki/QEMU/Guests/Windows_NT_3.x-4.0_(MIPS)). (ignore the networking switches, or replace ``dp83932`` with ``ne2k_isa``)
+5. Launch the installer by running ``cd:\mips\setupldr``.
+Additional information:
+![exhibit A; shows the 0x0000007b bugcheck output](/uploads/389e7b5fe77e259c6f3b2a703945df73/Screenshot_from_2024-07-28_18-44-15.png)
diff --git a/results/classifier/gemma3:12b/boot/2467 b/results/classifier/gemma3:12b/boot/2467
new file mode 100644
index 000000000..dc0665578
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2467
@@ -0,0 +1,32 @@
+
+OpenSBI 1.5 packaged in QEMU 9.0.50 fails to support poweroff with 'spike' board
+Steps to reproduce:
+Build upstream U-Boot:
+
+- git clone https://source.denx.de/u-boot/u-boot.git
+- cd u-boot
+- make qemu-riscv64_smode_defconfig
+- CROSS_COMPILE=riscv64-linux-gnu- make
+
+Run U-Boot and execute poweroff command
+
+- qemu-system-riscv64 -kernel u-boot.bin
+- poweroff
+
+Poweroff fails.
+
+When building upstream OpenSBI v1.5 with 
+
+- git clone https://github.com/riscv-software-src/opensbi.git
+- cd opensbi
+- git reset --hard v1.5
+- CROSS_COMPILE=riscv64-linux-gnu- make PLATFORM=generic
+
+and then running
+
+- qemu-system-riscv64 -bios fw_dynamic.bin -kernel u-boot.bin
+- poweroff
+
+poweroff succeeds.
+
+Please, distribute an unpatched OpenSBI v1.5 with QEMU.
diff --git a/results/classifier/gemma3:12b/boot/2470 b/results/classifier/gemma3:12b/boot/2470
new file mode 100644
index 000000000..8bae3794e
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2470
@@ -0,0 +1,32 @@
+
+qemu-system-mipsel regression, Linux generated with Buildroot does not boot anymore
+Description of problem:
+Buildroot Toolchain Builders try to release a new version. See a message from Thomas Petazzoni with the remaining issues:
+https://lore.kernel.org/buildroot/20240730223542.273693e5@windsurf/T/#u
+
+All toolchains generate a system that fails to boot:
+
+Run /sbin/init as init process
+process '/bin/busybox' started with executable stack
+Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
+
+The interesting thing is that those images boot fine with Qemu v8.2.6,
+but they fail to boot with Qemu v9.0.2.
+
+I tracked it down to this commit:
+commit 4e999bf4197ae3dc58b7092260f98146920a7469
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Sun Jan 28 15:58:52 2024 +1000
+
+    target/mips: Pass ptw_mmu_idx down from mips_cpu_tlb_fill
+    
+    Rather than adjust env->hflags so that the value computed
+    by cpu_mmu_index() changes, compute the mmu_idx that we
+    want directly and pass it down.
+    
+    Introduce symbolic constants for MMU_{KERNEL,ERL}_IDX.
+    
+    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+
+Unfortunately just reverting this commit in 9.0.2 does not help, Qemu segfaults on Linux Kernel boot then.
diff --git a/results/classifier/gemma3:12b/boot/2502 b/results/classifier/gemma3:12b/boot/2502
new file mode 100644
index 000000000..b4905756d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2502
@@ -0,0 +1,14 @@
+
+Old amd64 Ubuntu won't start
+Description of problem:
+While taking a trip down memory lane, I noticed that old Ubuntu amd64 live CDs won't boot in qemu-system-x86_64, while i386 ones work fine. I can confirm this for 6.06 and prior releases, while 8.04 and forward are OK (I don't have interim releases isos).
+Steps to reproduce:
+1. Launch qemu-system-x86_64 with Ubuntu 6.06.1 amd64 live CD
+2. Press "Start or install Ubuntu"
+3. PANIC: early exception rip (etc, please see screenshot below)
+Additional information:
+![Schermata_da_2024-08-13_22-07-14](/uploads/b25474a5bc984e330c1cec32677db2bb/Schermata_da_2024-08-13_22-07-14.png)
+
+I tried a few versions of QEMU and I can tell you that everything worked fine in 7.0.0 and it first broke in 7.1.0. I don't have a more precise bisect, sorry. I also tried in Fedora 40 with QEMU 8.2.2 and I have the same issue, so I don't think it's distro related.
+
+On the other hand, on a completely different PC with an Intel Core i3-330M I have no issue at all, even with QEMU 8.2.3, so it might be AMD/Ryzen related.
diff --git a/results/classifier/gemma3:12b/boot/2509 b/results/classifier/gemma3:12b/boot/2509
new file mode 100644
index 000000000..abbc5829b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2509
@@ -0,0 +1,27 @@
+
+With qemu-system-i386 certain iso images cause looping crashes
+Description of problem:
+Soon after start seabios tries to boot, a crash followed by a loop occurs. Last line seen before crash and loop:
+   ```
+Booting from DVD/CD...
+   ```
+Steps to reproduce:
+1. Download https://www.qemu-advent-calendar.org/2018/download/day10.tar.xz
+2. Execute QEMU command line
+Additional information:
+Starting VM with qemu-system-x86_64 works
+   ```
+   qemu-system-x86_64 -cdrom gamebro.iso
+   ```
+Starting VM with qemu-system-i386 using KVM causes looping
+   ```
+   qemu-system-i386 -accel kvm -cdrom gamebro.iso
+   ```
+Starting VM with qemu-system-i386 on Windows using WHPX works
+   ```
+   qemu-system-i386.exe -accel whpx -cdrom gamebro.iso
+   ```
+Starting other iso images works, e.g. https://cdimage.debian.org/mirror/cdimage/archive/10.8.0/i386/iso-cd/debian-10.8.0-i386-netinst.iso
+   ```
+   qemu-system-i386 -cdrom debian-10.8.0-i386-netinst.iso
+   ```
diff --git a/results/classifier/gemma3:12b/boot/2538 b/results/classifier/gemma3:12b/boot/2538
new file mode 100644
index 000000000..e9c3536c6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2538
@@ -0,0 +1,27 @@
+
+qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed.
+Description of problem:
+Cannot enter the loongarch64 UEFI shell due to the error below:
+qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed.
+Steps to reproduce:
+1.follow the steps to create an empty loongarch64 uefi bare metal.
+2.Click start the installation
+3.Then the error occurs.
+Additional information:
+```
+qemu-system-loongarch64: ../hw/loongarch/virt.c:118: virt_flash_map1: Assertion `QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE)' failed.'
+
+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/createvm.py", line 2008, in _do_async_install
+    installer.start_install(guest, meter=meter)
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install
+    domain = self._create_guest(
+             ^^^^^^^^^^^^^^^^^^^
+  File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest
+    domain = self.conn.createXML(initial_xml or final_xml, 0)
+             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  File "/usr/lib64/python3.12/site-packages/libvirt.py", line 4545, in createXML
+    raise libvirtError('virDomainCreateXML() failed')
+```
diff --git a/results/classifier/gemma3:12b/boot/2543 b/results/classifier/gemma3:12b/boot/2543
new file mode 100644
index 000000000..8057b9cc4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2543
@@ -0,0 +1,12 @@
+
+QEMU UEFI for riscv64 failed to load my DIY bootloader due to unknown reason
+Steps to reproduce:
+1. [ProblematicBootLoader.zip](/uploads/21fcff0052dc2dd95bf4bba3f6ec8fb8/ProblematicBootLoader.zip) unpack this zipped file,create a fat.img which contains FAT32 file system,and then move the unpacked file in the zip to /EFI/BOOT/bootriscv64.efi.After that using xorriso to pack it.
+2. Load the cdrom in libvirt(virt-manager) using SCSI/USB
+3. Then wait for seconds and error will show(I don't why STORE_ACCESS_PAGE_FAULT occurs)
+Additional information:
+My full source code is in https://github.com/TYDQSoft/UEFIPascalOS.
+
+You can get the instruction in the github to compile this problematic bootloader for testing.
+
+x64,AArch64 was tested successfully,but riscv64 is always problematic in evert test times.
diff --git a/results/classifier/gemma3:12b/boot/2558 b/results/classifier/gemma3:12b/boot/2558
new file mode 100644
index 000000000..5f7ce5479
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2558
@@ -0,0 +1,66 @@
+
+riscv64: Ubuntu doesn't boot with EDK2, although it boots with u-boot
+Description of problem:
+Ubuntu doesn't boot with `edk2-riscv-code.fd`:
+
+```bash
+wget https://cloud-images.ubuntu.com/noble/20240822/noble-server-cloudimg-riscv64.img
+
+qemu-system-riscv64 -M virt -m 2048 -nographic -hda noble-server-cloudimg-riscv64.img \
+  -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-riscv-code.fd
+```
+
+
+```
+Loading Linux 6.8.0-41-generic ...
+Loading initial ramdisk ...
+InstallProtocolInterface: 4006C0C1-FCB3-403E-996D-4A6C8724E06D FDB3F3C8
+InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B FDB3F380
+[Security] 3rd party image[0] can be loaded after EndOfDxe: MemoryMapped(0x2,0xF9CC4000,0xFC194000).
+InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B FF29C2C0
+Loading driver at 0x000F732C000 EntryPoint=0x000F817FEA6 
+InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF FF29CC18
+ProtectUefiImageCommon - 0xFF29C2C0
+  - 0x00000000F732C000 - 0x0000000002598000
+SetUefiImageMemoryAttributes - 0x00000000F732C000 - 0x0000000000001000 (0x0000000000004000)
+SetUefiImageMemoryAttributes - 0x00000000F732D000 - 0x0000000000FFF000 (0x0000000000020000)
+SetUefiImageMemoryAttributes - 0x00000000F832C000 - 0x0000000001598000 (0x0000000000004000)
+TimerDriverSetTimerPeriod(0x0)
+SetUefiImageMemoryAttributes - 0x00000000FFEC7000 - 0x000000000000C000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFEBC000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFEAC000 - 0x0000000000010000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFEA1000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE84000 - 0x000000000001D000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE79000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE6E000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE63000 - 0x000000000000B000 (0x0000000000000000)
+SetUefiImageMemoryAttributes - 0x00000000FFE59000 - 0x000000000000A000 (0x0000000000000000)
+(hangs here)
+```
+
+The same disk image still boots when `uboot.elf` is specified as the kernel image:
+
+```bash
+wget https://github.com/lima-vm/u-boot-qemu-mirror/releases/download/2023.07%2Bdfsg-1/qemu-riscv64_smode_uboot.elf
+
+qemu-system-riscv64 -M virt -m 2048 -nographic -hda noble-server-cloudimg-riscv64.img \
+  -kernel qemu-riscv64_smode_uboot.elf
+```
+
+```
+Loading Linux 6.8.0-41-generic ...
+Loading initial ramdisk ...
+syscon-poweroff poweroff: pm_power_off already claimed for sbi_srst_power_off
+-.mount
+etc-machine\x2did.mount
+systemd-journald.service
+dev-hugepages.mount
+...
+Ubuntu 24.04 LTS ubuntu ttyS0
+
+ubuntu login:
+```
+Steps to reproduce:
+See above
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/260 b/results/classifier/gemma3:12b/boot/260
new file mode 100644
index 000000000..a3f2f8618
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/260
@@ -0,0 +1,2 @@
+
+qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso
diff --git a/results/classifier/gemma3:12b/boot/2620 b/results/classifier/gemma3:12b/boot/2620
new file mode 100644
index 000000000..52ea87135
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2620
@@ -0,0 +1,10 @@
+
+Freezes when installing NeXTSTEP 3.3 or OPENSTEP 4.2 RISC version in qemu-system-sparc
+Description of problem:
+
+Steps to reproduce:
+1.Boot from NeXTstep 3.3 or OPENSTEP 4.2 RISC ISO.  Works on real Sparcstation 5, 10, or 20
+2.Start OS install
+3.
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/2636 b/results/classifier/gemma3:12b/boot/2636
new file mode 100644
index 000000000..dd1425d73
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2636
@@ -0,0 +1,2 @@
+
+ast2600 fails to run u-boot
diff --git a/results/classifier/gemma3:12b/boot/2654 b/results/classifier/gemma3:12b/boot/2654
new file mode 100644
index 000000000..065514533
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2654
@@ -0,0 +1,15 @@
+
+qemu-system-i386 no longer boots NetBSD
+Description of problem:
+Since qemu commit b56617bbcb473c25815d1bf475e326f84563b1de, qemu-system-i386 can no longer boot NetBSD.
+Steps to reproduce:
+```
+wget https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-i386.iso
+qemu-system-i386 -cdrom NetBSD-10.0-i386.iso
+```
+
+Expected behavior: Boots into the NetBSD installer
+
+Observed incorrect behavior: Boot hangs with a black screen
+Additional information:
+This regression is a critical issue to the NetBSD project as its automated testing infrastructure is heavily dependent on qemu-system-i386.
diff --git a/results/classifier/gemma3:12b/boot/2660 b/results/classifier/gemma3:12b/boot/2660
new file mode 100644
index 000000000..968b0c450
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2660
@@ -0,0 +1,2 @@
+
+EDK2 subhook submodule missing
diff --git a/results/classifier/gemma3:12b/boot/2682 b/results/classifier/gemma3:12b/boot/2682
new file mode 100644
index 000000000..cd862f892
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2682
@@ -0,0 +1,42 @@
+
+QEMU throws errors at the beginning of building
+Description of problem:
+QEMU throws errors at the beginning of building:
+```
+ninja: no work to do.
+/tmp/qemu-8.1.5/build/pyvenv/bin/meson introspect --targets --tests --benchmarks | /tmp/qemu-8.1.5/build/pyvenv/bin/python3 -B scripts/mtest2make.py > Makefile.mtest
+pc-bios/optionrom: -fcf-protection=none detected
+pc-bios/optionrom: -fno-pie detected
+pc-bios/optionrom: -no-pie detected
+pc-bios/optionrom: -fno-stack-protector detected
+pc-bios/optionrom: -Wno-array-bounds detected
+pc-bios/optionrom: Assembling multiboot.o
+pc-bios/optionrom: Assembling linuxboot.o
+pc-bios/optionrom: Assembling multiboot_dma.o
+pc-bios/optionrom: Compiling linuxboot_dma.o
+pc-bios/optionrom: Assembling pvh.o
+pc-bios/optionrom: Assembling kvmvapic.o
+pc-bios/optionrom: Compiling pvh_main.o
+pc-bios/optionrom: Linking multiboot.img
+pc-bios/optionrom: Linking linuxboot.img
+pc-bios/optionrom: Linking kvmvapic.img
+pc-bios/optionrom: Extracting raw object multiboot.raw
+/bin/sh: 1: -O: not found
+make[1]: *** [Makefile:53: multiboot.raw] Error 127
+make[1]: *** Waiting for unfinished jobs....
+pc-bios/optionrom: Linking multiboot_dma.img
+pc-bios/optionrom: Extracting raw object linuxboot.raw
+/bin/sh: 1: -O: not found
+make[1]: *** [Makefile:53: linuxboot.raw] Error 127
+make: *** [Makefile:190: pc-bios/optionrom/all] Error 2
+make: *** Waiting for unfinished jobs....
+[1/10003] Generating trace/trace-hw_i2c.h with a custom command
+
+...
+```
+Then proceeds the building. Whether it is failing at the end is not reliabily reproducible as it do fail one time and builds successfully at the next time. However, i don't know if these errors will cause runtime problems in the case of a successful build.
+Steps to reproduce:
+1. `../configure --enable-strip --audio-drv-list=alsa --enable-tools --enable-modules`
+2. `make -j16`
+Additional information:
+Configuration log is available here: http://oscomp.hu/depot/qemu-8.1.5-configure.log
diff --git a/results/classifier/gemma3:12b/boot/2686 b/results/classifier/gemma3:12b/boot/2686
new file mode 100644
index 000000000..3c51c91e7
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2686
@@ -0,0 +1,49 @@
+
+rng-seed addition causing test_loongarch64_virt.py to hang in EFI startup
+Description of problem:
+Since the rng-seed addition, the test_loongarch64_virt.py test will periodically hang.
+
+git bisect blames this
+
+```
+commit d9bd1ccbf1d84d872aed684c65fec33814b8ac1b
+Author: Jason A. Donenfeld <Jason@zx2c4.com>
+Date:   Thu Sep 5 17:33:16 2024 +0200
+
+    hw/loongarch: virt: pass random seed to fdt
+    
+    If the FDT contains /chosen/rng-seed, then the Linux RNG will use it to
+    initialize early. Set this using the usual guest random number
+    generation function.
+    
+    This is the same procedure that's done in b91b6b5a2c ("hw/microblaze:
+    pass random seed to fdt"), e4b4f0b71c ("hw/riscv: virt: pass random seed
+    to fdt"), c6fe3e6b4c ("hw/openrisc: virt: pass random seed to fdt"),
+    67f7e426e5 ("hw/i386: pass RNG seed via setup_data entry"), c287941a4d
+    ("hw/rx: pass random seed to fdt"), 5e19cc68fb ("hw/mips: boston: pass
+    random seed to fdt"), 6b23a67916 ("hw/nios2: virt: pass random seed to fdt")
+    c4b075318e ("hw/ppc: pass random seed to fdt"), and 5242876f37
+    ("hw/arm/virt: dt: add rng-seed property").
+    
+    These earlier commits later were amended to rerandomize the RNG seed on
+    snapshot load, but the LoongArch code somehow already does that, despite
+    not having this patch here, presumably due to some lucky copy and
+    pasting.
+    
+    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
+    Reviewed-by: Song Gao <gaosong@loongson.cn>
+    Message-Id: <20240905153316.2038769-1-Jason@zx2c4.com>
+    Signed-off-by: Song Gao <gaosong@loongson.cn>
+```
+
+When it hangs, test_loongarch64_virt.py will get stuck waiting for serial console output from the guest.
+
+Looking at the console.log file shows it to be completely empty. 
+
+This appears to indicate it has hung before EDK has even initialized, as it has not even printed the 'Entering C environment' message
+Steps to reproduce:
+1. ./configure --target-list=loongarch64-softmmu
+2. make -j 20
+3. n=0 ; while true ; do n=$(expr $n + 1); echo $n ; QEMU_TEST_QEMU_BINARY=./build/qemu-system-loongarch64  PYTHONPATH=./python ./tests/functional/test_loongarch64_virt.py  ; done
+
+Most commonly it will hang within 10 iterations, very occasionally needing upto 25
diff --git a/results/classifier/gemma3:12b/boot/269 b/results/classifier/gemma3:12b/boot/269
new file mode 100644
index 000000000..fbadfa976
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/269
@@ -0,0 +1,2 @@
+
+AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu
diff --git a/results/classifier/gemma3:12b/boot/2700 b/results/classifier/gemma3:12b/boot/2700
new file mode 100644
index 000000000..1e0512f03
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2700
@@ -0,0 +1,9 @@
+
+Windows 11 24H2 (x64) fails to boot
+Description of problem:
+When trying to boot Windows 11 24H2 (including the installer), the guest will just restart.
+Steps to reproduce:
+1. Download Windows 11 ISO from: https://www.microsoft.com/en-us/software-download/windows11
+2. Run the command above
+Additional information:
+I tested it on an M4 Pro Mac running TCG. Other users have reported the same issue with M3 running TCG and Intel i9 running HVF.
diff --git a/results/classifier/gemma3:12b/boot/2723 b/results/classifier/gemma3:12b/boot/2723
new file mode 100644
index 000000000..ac78ea467
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2723
@@ -0,0 +1,24 @@
+
+qemu-system-sparc: nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled
+Description of problem:
+It boots into the BIOS. I connect to the monitor on port 4444, and send "sendkey stop-a", and then in the main window (VNC session) I enter "boot disk1:d". It starts to load vmunix, and then crashes with:-
+   ```
+nesqemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state
+pc: f00053dc  npc: f00053e0
+%g0-7: 00000000 f00ee048 00000000 ffef0000 ffef9b6c f00e1000 00000000 ffefebc4
+%o0-7: 00008000 00008000 000000e0 feff8008 00001ff0 00000068 f00d7490 f0005c98 
+%l0-7: 04800fc1 f0005d14 f0005d18 00000002 0000010f 00000002 00000007 f00d6f50 
+%i0-7: 00008000 00008000 00000005 feff8008 00000000 00000000 f00d6ff8 f0005c98 
+%f00:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f08:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f16:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+%f24:  0000000000000000 0000000000000000 0000000000000000 0000000000000000
+psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002
+fsr: 00080000 y: 00000000
+
+Aborted (core dumped)
+   ```
+Additional information:
+md5sums (both files can be found online)
+ede0690b3cb3d2abb6bddd8136912106  Solaris1_1_2.iso
+6364e9a6f5368e2ecc4e9c1d915a93ae  ss5.bin
diff --git a/results/classifier/gemma3:12b/boot/2729 b/results/classifier/gemma3:12b/boot/2729
new file mode 100644
index 000000000..65370d8a5
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2729
@@ -0,0 +1,75 @@
+
+qemu-system-aarch64 -M raspi4b -- no valid DTB provided in x0 register
+Description of problem:
+When starting `qemu-system-aarch64 -M raspi4b`, no valid DTB is provided in x0.
+Steps to reproduce:
+Make a simple binary to loop forever
+
+```
+$ cat loop.c
+void _start(void)
+{
+	for(;;)
+		;
+}
+$ aarch64-linux-gnu-gcc loop.c -nostdlib
+$ aarch64-linux-gnu-objcopy -O binary a.out loop.bin
+```
+
+Start qemu for debugging and start gdb
+
+```
+$ qemu-system-aarch64 -S -s -M raspi4b -kernel loop.bin
+# in another terminal
+$ aarch64-linux-gnu-gdb
+(gdb) target remote :1234
+Remote debugging using :1234
+warning: No executable has been specified and target does not support
+determining executable automatically.  Try using the "file" command.
+0x0000000000000000 in ?? ()
+(gdb) watch *$x0
+Watchpoint 3: *$x0
+(gdb) watch $x0
+Watchpoint 4: $x0
+(gdb) x/2x$x0
+0x0:	0x580000c0	0xaa1f03e1
+(gdb) si
+
+Thread 1 hit Watchpoint 3: *$x0
+
+Old value = 1476395200
+New value = 5
+
+Thread 1 hit Watchpoint 4: $x0
+
+Old value = 0
+New value = 256
+0x0000000000000004 in ?? ()
+(gdb) x/2x$x0
+0x100:	0x00000005	0x54410001
+(gdb) si
+0x0000000000000008 in ?? ()
+(gdb) si
+0x000000000000000c in ?? ()
+(gdb) si
+0x000000000000000c in ?? ()
+(gdb) si
+0x0000000000000010 in ?? ()
+(gdb) si
+0x0000000000000014 in ?? ()
+(gdb) si
+0x0000000000080000 in ?? ()
+(gdb) si
+0x0000000000000200 in ?? ()
+(gdb) si
+0x0000000000000200 in ?? ()
+(gdb) si
+0x0000000000000200 in ?? ()
+(gdb) si
+0x0000000000000200 in ?? ()
+(gdb) x/2x$x0
+0x100:	0x00000005	0x54410001
+(gdb) 
+```
+
+Note that at no time is a valid DTB provided in x0. I expected to see the DTB magic 0xd00dfeed (or 0xedfe0dd0) at the memory pointed to by x0
diff --git a/results/classifier/gemma3:12b/boot/2739 b/results/classifier/gemma3:12b/boot/2739
new file mode 100644
index 000000000..554664e5b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2739
@@ -0,0 +1,4 @@
+
+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/gemma3:12b/boot/2741 b/results/classifier/gemma3:12b/boot/2741
new file mode 100644
index 000000000..c8c7aeb0c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2741
@@ -0,0 +1,62 @@
+
+qemu-system-ppc no longer boots NetBSD/macppc
+Description of problem:
+Since commit 7419dc5b2b5bcc929d91e8920692041a8f6d1977, qemu no longer boots NetBSD/macppc.
+Steps to reproduce:
+```
+wget https://www.gson.org/bugs/qemu/macppc-20241221/boot.iso.gz
+wget https://www.gson.org/bugs/qemu/macppc-20241221/wd0.img.gz
+gunzip boot.iso.gz
+gunzip wd0.img.gz
+qemu-system-ppc \
+    -m 256 \
+    -nographic \
+    -drive file=wd0.img,format=raw,media=disk,snapshot=on \
+    -drive file=boot.iso,format=raw,media=cdrom,readonly=on,index=2 \
+    -prom-env boot-device=cd:,netbsd-GENERIC \
+    -M mac99 \
+    -prom-env qemu_boot_hack=y
+```
+
+At the "root device:" prompt, enter `wd0a`
+
+At the "dump device" prompt, just press enter
+
+At the "file system" prompt, just press enter
+
+At the "init path" prompt, just press enter
+
+Expected behavior: The guest system boots to a login prompt
+
+Observed behavior: qemu exits with the following error message:
+
+```
+qemu: fatal: Raised an exception without defined vector 94
+
+NIP fdb5d440   LR fdb5dc20 CTR fd62a340 XER 20000000 CPU#0
+MSR 0200d032 HID0 809400a4  HF 02004012 iidx 0 didx 0
+TB 00000000 831919972 DECR 105840
+GPR00 0000000000000125 00000000ffffe8b0 00000000fde90008 0000000000000000
+GPR04 0000000000000000 00000000fdcfebac 00000000fdcfeb48 0000000000000001
+GPR08 0000000000000000 00000000fde90008 00000000ffffe8b0 00000000fdb5dc14
+GPR12 0000000044004482 0000000000000000 00000000fdee0efc 00000000fdef57f0
+GPR16 00000000fdef57c8 0000000000000000 00000000ffffea94 00000000ffffeac8
+GPR20 00000000fdee0f3c 0000000001800114 0000000000000000 0000000000000001
+GPR24 0000000000000000 00000000fdef57e0 0000000000000001 00000000fdb5da2c
+GPR28 00000000ffffe9c0 00000000ffffe8f8 00000000fdcffb4c 00000000fdcfeb48
+CR 24004482  [ E  G  -  -  G  G  L  E  ]     RES 004@ffffffff
+FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPSCR 00000000
+ SRR0 fd62a360  SRR1 0200d032    PVR 000c0209 VRSAVE 00000000
+SPRG0 00c02bc0 SPRG1 44004482  SPRG2 fde90008  SPRG3 00000000
+SPRG4 00000000 SPRG5 00000000  SPRG6 00000000  SPRG7 00000000
+ SDR1 00e0001f   DAR cd538000  DSISR 42000000
+Aborted
+```
diff --git a/results/classifier/gemma3:12b/boot/2807 b/results/classifier/gemma3:12b/boot/2807
new file mode 100644
index 000000000..a73b770ff
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2807
@@ -0,0 +1,32 @@
+
+DOUBLE MMU FAULT when running -M virt in qemu-system-m68k
+Description of problem:
+When running qemu-system-m68k with the -M virt machine type, a DOUBLE MMU FAULT occurs immediately upon startup, even without any BIOS, disk image, or additional configuration.
+Steps to reproduce:
+1. qemu-system-m68k -M virt -m 4M -serial stdio
+
+QEMU crashes immediately with the following output:
+```
+qemu: fatal: DOUBLE MMU FAULT
+D0 = 00000000   A0 = 00000000   F0 = 7fff ffffffffffffffff  (         nan)
+D1 = 00000000   A1 = 00000000   F1 = 7fff ffffffffffffffff  (         nan)
+D2 = 00000000   A2 = 00000000   F2 = 7fff ffffffffffffffff  (         nan)
+D3 = 00000000   A3 = 00000000   F3 = 7fff ffffffffffffffff  (         nan)
+D4 = 00000000   A4 = 00000000   F4 = 7fff ffffffffffffffff  (         nan)
+D5 = 00000000   A5 = 00000000   F5 = 7fff ffffffffffffffff  (         nan)
+D6 = 00000000   A6 = 00000000   F6 = 7fff ffffffffffffffff  (         nan)
+D7 = 00000000   A7 = 00000000   F7 = 7fff ffffffffffffffff  (         nan)
+PC = 00400000   SR = 2704 T:0 I:7 SI --Z--
+FPSR = 00000000 ----
+                                FPCR =     0000 X RN
+  A7(MSP) = 00000000   A7(USP) = 00000000 ->A7(ISP) = 00000000
+VBR = 0x00000000
+SFC = 0 DFC 0
+SSW 00000105 TCR 00000000 URP 00000000 SRP 00000000
+DTTR0/1: 00000000/00000000 ITTR0/1: 00000000/00000000
+MMUSR 00000000, fault at fffffffc
+```
+Additional information:
+The issue seems to be related to incorrect memory initialization, causing a fault at address fffffffc.
+The PC = 00400000 suggests that QEMU is jumping to an invalid address early in the boot process.
+The fact that the fault is consistent across different configurations (q800, next-cube, etc) points to a possible regression or incomplete memory initialization in the virt machine.
diff --git a/results/classifier/gemma3:12b/boot/2810 b/results/classifier/gemma3:12b/boot/2810
new file mode 100644
index 000000000..d76ecd723
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2810
@@ -0,0 +1,2 @@
+
+Boot zboot images on riscv64 and loogarch64
diff --git a/results/classifier/gemma3:12b/boot/2823 b/results/classifier/gemma3:12b/boot/2823
new file mode 100644
index 000000000..1a89e2654
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2823
@@ -0,0 +1,44 @@
+
+func-aarch64-aarch64_rme_virt function test hangs especially when built with --enable-debug
+Description of problem:
+
+Steps to reproduce:
+1. Build with ../../configure --enable-debug
+2. ./pyvenv/bin/meson test --setup thorough --suite func-thorough func-aarch64-aarch64_rme_virt
+3. repeat until hang
+Additional information:
+Comparing a normal build to the hang:
+
+```
+2025-02-20 16:54:15,519: NOTICE:  Booting Trusted Firmware    | 2025-02-20 16:16:06,740: NOTICE:  Booting Trusted Firmware
+2025-02-20 16:54:15,519: NOTICE:  BL1: v2.11.0(release):f2f94 | 2025-02-20 16:16:06,740: NOTICE:  BL1: v2.11.0(release):f2f94
+2025-02-20 16:54:15,519: NOTICE:  BL1: Built : 17:54:58, Dec  | 2025-02-20 16:16:06,740: NOTICE:  BL1: Built : 17:54:58, Dec 
+2025-02-20 16:54:15,520: NOTICE:  BL1: Booting BL2            | 2025-02-20 16:16:06,741: NOTICE:  BL1: Booting BL2
+2025-02-20 16:54:15,522: NOTICE:  BL2: v2.11.0(release):f2f94 | 2025-02-20 16:16:06,743: NOTICE:  BL2: v2.11.0(release):f2f94
+2025-02-20 16:54:15,522: NOTICE:  BL2: Built : 17:55:12, Dec  | 2025-02-20 16:16:06,743: NOTICE:  BL2: Built : 17:55:12, Dec 
+2025-02-20 16:54:15,545: NOTICE:  BL2: Booting BL31           | 2025-02-20 16:16:06,762: NOTICE:  BL2: Booting BL31
+2025-02-20 16:54:15,550: NOTICE:  BL31: v2.11.0(release):f2f9 | 2025-02-20 16:16:06,768: NOTICE:  BL31: v2.11.0(release):f2f9
+2025-02-20 16:54:15,550: NOTICE:  BL31: Built : 17:55:22, Dec | 2025-02-20 16:16:06,768: NOTICE:  BL31: Built : 17:55:22, Dec
+2025-02-20 16:54:15,555: Booting RMM v.0.5.0(release) 1b6bdf8 | 2025-02-20 16:16:06,774: Booting RMM v.0.5.0(release) 1b6bdf8
+2025-02-20 16:54:15,556: RMM-EL3 Interface v.0.4              | 2025-02-20 16:16:06,774: RMM-EL3 Interface v.0.4
+2025-02-20 16:54:15,556: Boot Manifest Interface v.0.3        | 2025-02-20 16:16:06,775: Boot Manifest Interface v.0.3
+2025-02-20 16:54:15,556: RMI/RSI ABI v.1.0/1.0 built: Dec  2  | 2025-02-20 16:16:06,775: RMI/RSI ABI v.1.0/1.0 built: Dec  2 
+2025-02-20 16:54:15,587: UEFI firmware (version  built at 17: | 2025-02-20 16:16:06,837: UEFI firmware (version  built at 17:
+2025-02-20 16:54:15,876: ESC[2JESC[01;01HESC[=3hESC[2JESC[01;01HESC[2JESC[01;01HESC[= | 2025-02-20 16:16:07,420: ESC[2JESC[01;01HESC[=3hESC[2JESC[01;01HESC[2JESC[01;01HESC[=
+2025-02-20 16:54:15,898: EFI stub: Using DTB from configurati | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:15,898: EFI stub: Exiting boot services...   | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,170: [    0.000000] Booting Linux on phys | 2025-02-20 16:16:07,421: Synchronous Exception at 0x00000000B
+2025-02-20 16:54:16,171: [    0.000000] Linux version 6.12.0- | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,171: [    0.000000] KASLR enabled         | 2025-02-20 16:16:07,421: 
+2025-02-20 16:54:16,171: [    0.000000] random: crng init don | 2025-02-20 16:16:07,421: Synchronous Exception at 0x00000000B
+2025-02-20 16:54:16,171: [    0.000000] Machine model: linux, <
+2025-02-20 16:54:16,171: [    0.000000] efi: EFI v2.7 by EDK  <
+2025-02-20 16:54:16,171: [    0.000000] efi: SMBIOS=0xbf3c000 <
+2025-02-20 16:54:16,171: [    0.000000] OF: reserved mem: 0x0 <
+2025-02-20 16:54:16,171: [    0.000000] NUMA: Faking a node a <
+2025-02-20 16:54:16,171: [    0.000000] NODE_DATA(0) allocate <
+2025-02-20 16:54:16,171: [    0.000000] Zone ranges:          <
+2025-02-20 16:54:16,171: [    0.000000]   DMA      [mem 0x000 <
+2025-02-20 16:54:16,171: [    0.000000]   DMA32    empty      <
+2025-02-20 16:54:16,171: [    0.000000]   Normal   empty      <
+```
diff --git a/results/classifier/gemma3:12b/boot/2840 b/results/classifier/gemma3:12b/boot/2840
new file mode 100644
index 000000000..ed83c6068
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2840
@@ -0,0 +1,22 @@
+
+After converting the Windows 10 system disk from qcow2 to LUKS format with pre-allocated space, the system fails to boot
+Description of problem:
+When converting a qcow2 file containing an installed Windows 10 system to LUKS format, using the --target-is-zero parameter in the conversion command prevents the LUKS image from shrinking. However, when attempting to boot the virtual machine with the converted LUKS file, VNC login shows a black screen, and the system fails to start. If the conversion is performed without the --target-is-zero parameter, the system boots up normally
+Steps to reproduce:
+1. create a luks image
+qemu-img create -f qcow2 --object secret,data=123,id=sec0 -o preallocation=full,encrypt.format=luks,encrypt.key-secret=sec0 encry_ok.qcow2 50G
+2.
+qemu-img convert -t none -T none --object secret,id=sec0,data=123 -f qcow2 ./windows10.qcow2  -n -m 1 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=encry_ok.qcow2 --target-is-zero
+
+windows10.qcow2 container windows20 system and  it can be booted
+3.
+./qemu-system-x86_64  -accel kvm -cpu SandyBridge  -object memory-backend-memfd,id=mem1,size=4G -machine memory-backend=mem1  -smp 4  -object secret,id=sec0,data=123,format=raw -drive if=none,driver=qcow2,file.filename=/sdc1/luzhipeng/encry_ok.qcow2,encrypt.key-secret=sec0,id=drive0,cache=none  -device virtio-blk,drive=drive0,bootindex=1  -monitor stdio -vnc :4
+
+4. vnc shows a black screen, and the system fails to start
+
+5. if use convert command:
+qemu-img convert -t none -T none --object secret,id=sec0,data=123 -f qcow2 ./windows10.qcow2  -n -m 1 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=encry_ok.qcow2
+
+6. the windows10 system can start successful
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/2842 b/results/classifier/gemma3:12b/boot/2842
new file mode 100644
index 000000000..f5286a8c0
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2842
@@ -0,0 +1,2 @@
+
+RX System emulator boot, kernel images and device tree blob are missing
diff --git a/results/classifier/gemma3:12b/boot/2847 b/results/classifier/gemma3:12b/boot/2847
new file mode 100644
index 000000000..20da2f6d2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2847
@@ -0,0 +1,2 @@
+
+Provide short option for UEFI firmware
diff --git a/results/classifier/gemma3:12b/boot/2887 b/results/classifier/gemma3:12b/boot/2887
new file mode 100644
index 000000000..3303fc573
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2887
@@ -0,0 +1,2 @@
+
+Qemu VM WHPX Startup Error with OVMF Code and VARS UEFI Files
diff --git a/results/classifier/gemma3:12b/boot/2891 b/results/classifier/gemma3:12b/boot/2891
new file mode 100644
index 000000000..ed1e07011
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2891
@@ -0,0 +1,2 @@
+
+qemu-system-x86_64 segfaults when executing ipxe selftests
diff --git a/results/classifier/gemma3:12b/boot/2893 b/results/classifier/gemma3:12b/boot/2893
new file mode 100644
index 000000000..405e9aa66
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2893
@@ -0,0 +1,13 @@
+
+with m4 mac mini windows 11 arm 64 iso not booting for installation
+Description of problem:
+Trying to run win11 arm 64 version in m4 mac mini and the ios failed to boot 
+
+i went to the efi shell and tried to boot from there and it just hangs no problem reported 
+
+when i attach the serial to stdio i get the error convertprogress failed to find range errors
+Steps to reproduce:
+1. In m4 mac mini download win11 arm 64 iso from microsoft site
+2. run the above mentioned command and you will see that it does not boot
+
+/label ~"kind::Bug"
diff --git a/results/classifier/gemma3:12b/boot/2915 b/results/classifier/gemma3:12b/boot/2915
new file mode 100644
index 000000000..0839a4e85
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2915
@@ -0,0 +1,30 @@
+
+qemu: error reading initrd /home/build/pooldir/w.linux.initramfs
+Description of problem:
+occasionally, qemu can't open the initrd file it's been supplied on the command line (I'm guessing this is qemu and not libvirt)
+
+```
+sudo virsh --connect qemu:///system start w.east --console
+error: Failed to start domain 'w.east'\r\nerror: internal error: QEMU unexpectedly closed the monitor (vm='w.east'): qemu: error reading initrd /home/build/pooldir/w.linux-transmogrify.initramfs: Failed to open file \xe2\x80\x9c/home/build/pooldir/w.linux-transmogrify.initramfs\xe2\x80\x9d: open() failed: Permission denied\r\n\r\n"
+```
+Steps to reproduce:
+1. create, using libvirt, a config that direct boots from initrd and kernel
+it creates a domain call linux, and from that creates {w.,w1,w2,w3}{east,west,north,road}
+1. boots and then destroys these domains 1000's of times
+2. occasionally above error occurs while trying to boot the domain
+Additional information:
+I suspect it is this:
+```
+        mapped_file = g_mapped_file_new(initrd_filename, false, &gerr);
+        if (!mapped_file) {
+            fprintf(stderr, "qemu: error reading initrd %s: %s\n",
+                    initrd_filename, gerr->message);
+            exit(1);
+        }
+        x86ms->initrd_mapped_file = mapped_file;
+```
+in `hw/i386/x86-common.c`.  Which would suggest `g_mapped_file_new()` occasionally fails, which is worrying.
+
+The test framework is [Libreswan](https://testing.libreswan.org/), unresolved test results indicate a failed boot, for instance [debug log of failure](https://testing.libreswan.org/v5.2-370-ga09c7f410b/interop-ikev2-strongswan-20-strongswan-eap/OUTPUT/debug.log).
+
+The problem didn't happen with f40.
diff --git a/results/classifier/gemma3:12b/boot/2930 b/results/classifier/gemma3:12b/boot/2930
new file mode 100644
index 000000000..ffbbc9e31
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2930
@@ -0,0 +1,2 @@
+
+Versions after QEMU9.0 cannot boot vxworks on sifive_u
diff --git a/results/classifier/gemma3:12b/boot/2940 b/results/classifier/gemma3:12b/boot/2940
new file mode 100644
index 000000000..322aaaf56
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2940
@@ -0,0 +1,2 @@
+
+Fix i cant boot nextstep os in qemu m68k using next-cube
diff --git a/results/classifier/gemma3:12b/boot/2944 b/results/classifier/gemma3:12b/boot/2944
new file mode 100644
index 000000000..1f3e310ca
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2944
@@ -0,0 +1,22 @@
+
+Commit 59754f85 introduces regression with U-Boot on Cortex-A9 platforms
+Description of problem:
+In U-Boot CI, we started to update from v8.2.0 to v9.2.3 and found that the vexpress_ca9x4 platform was now failing one of the CI tests. I have reconfirmed the problem on top of tree QEMU, and bisected the failure to commit [59754f85("target/arm: Do memory type alignment check when translation disabled
+")](https://gitlab.com/qemu-project/qemu/-/commit/59754f85ed35cbd5f4bf2663ca2136c78d5b2413). I have also re-verified the test is fine on a physical platform with a Cortex-A9 that is as follows (per the RM):
+```
+Table 12-2. Cortex-A9 revision
+Core MP004-BU-50000-r2p10-0rel0
+NEON AT397-BU-50001- r2p0-00rel0
+PL310 PL310-BU-00000-r3p2-50rel0
+```
+Steps to reproduce:
+1. git clone https://source.denx.de/u-boot/u-boot.git; cd u-boot
+2. make O=/tmp/vexpress_ca9x4 CROSS_COMPILE=arm-linux-gnueabi- vexpress_ca9x4_config
+3. make O=/tmp/vexpress_ca9x4 CROSS_COMPILE=arm-linux-gnueabi- -sj$(nproc)
+4. qemu-system-arm -nographic -m 1G -audio none -net user,tftp=/tmp/vexpress_ca9x4 -net nic -M vexpress-a9 -kernel /tmp/vexpress_ca9x4/u-boot
+5. Stop autoboot with any key
+6. setenv autoload no
+7. dhcp
+8. tftpboot 60200000 lib/efi_loader/helloworld.efi
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/2957 b/results/classifier/gemma3:12b/boot/2957
new file mode 100644
index 000000000..8e62fab90
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2957
@@ -0,0 +1,29 @@
+
+qemu-system-riscv32: Some ROM regions are overlapping
+Description of problem:
+Booting the image produces:
+```
+qemu-system-riscv32: Some ROM regions are overlapping
+These ROM regions might have been loaded by direct user request or by default.
+They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
+Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
+
+The following two regions overlap (in the memory address space):
+  output/images/fw_jump.elf ELF program header segment 1 (addresses 0x0000000000000000 - 0x00000000000278cc)
+  mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028)
+```
+Steps to reproduce:
+1. `make qemu_riscv32_virt_defconfig`
+2. `make`
+3. `qemu-system-riscv32 \
+-M virt -nographic \
+-bios output/images/fw_jump.elf \
+-kernel output/images/Image \
+-append "root=/dev/vda ro" \
+-drive file=output/images/rootfs.ext2,format=raw,id=hd0 \
+-device virtio-blk-device,drive=hd0 \
+-netdev user,id=net0 -device virtio-net-device,netdev=net0`
+Additional information:
+Changing `-bios output/images/fw_jump.elf` to `-bios output/images/fw_jump.bin` or `-bios output/images/fw_dynamic.bin` resolves the issue.
+
+Similar issue observed elsewhere, e.g. here [https://github.com/riscv-software-src/opensbi/issues/372](https://github.com/riscv-software-src/opensbi/issues/372)
diff --git a/results/classifier/gemma3:12b/boot/2973 b/results/classifier/gemma3:12b/boot/2973
new file mode 100644
index 000000000..bf3a62918
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2973
@@ -0,0 +1,64 @@
+
+ast2700a0-evb machine hangs in U-Boot when trying to determine the RAM size
+Description of problem:
+On a BE host, the ast2700a0-evb machine hangs in U-Boot when trying to determine the RAM size if the RAM size is set to a value other than 8 GB.
+Steps to reproduce:
+1. ./qemu-system-aarch64 -machine ast2700a0-evb  -m 1g 
+2.
+3.
+Additional information:
+On a BE host, if I run an ast2700a0-evb machine :
+   ```
+   $ qemu-system-aarch64 -machine ast2700a0-evb  ...
+   ...
+   U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
+
+   SOC: AST2700-A0
+   Model: AST2700 EVB
+   DRAM:  8 GiB (effective 0 Bytes)
+   ```
+
+QEMU hangs.
+
+If the RAM size is defined to 8g
+   ```
+   $ qemu-system-aarch64 -machine ast2700a0-evb -m 8g  ...
+   ...
+   U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
+
+   SOC: AST2700-A0
+   Model: AST2700 EVB
+   DRAM:  8 GiB
+   aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
+   Core:  125 devices, 27 uclasses, devicetree: separate
+   ```
+
+machine boots.
+
+Whereas, with an ast2700a1-evb machine :
+   ```
+   $ qemu-system-aarch64 -machine ast2700a1-evb  ...
+   ...
+   U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
+
+   SOC: AST2700-A1
+   Model: AST2700 EVB
+   DRAM:  1 GiB
+   aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
+   Core:  125 devices, 27 uclasses, devicetree: separate
+   ```
+
+machine boots.
+   ```
+   $ qemu-system-aarch64 -machine ast2700a1-evb -m 8g  ...
+   ...
+   U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
+
+   SOC: AST2700-A1
+   Model: AST2700 EVB
+   DRAM:  8 GiB
+   aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
+   Core:  125 devices, 27 uclasses, devicetree: separate
+   ```
+
+machine boots.
diff --git a/results/classifier/gemma3:12b/boot/2987 b/results/classifier/gemma3:12b/boot/2987
new file mode 100644
index 000000000..c72a0f1f4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/2987
@@ -0,0 +1,8 @@
+
+QEMU TCG failed to boot Windows 98 Second Edition
+Description of problem:
+QEMU TCG failed at booting Windows 98 Second Edition 4.10.2222B.
+
+Bisected to commit e54ef98c8a80d16158bab4341d9a898701270528
+Additional information:
+![Screenshot_2025-05-29_at_5.15.14_PM](/uploads/1cf0cf2435c1227df895f37496239c66/Screenshot_2025-05-29_at_5.15.14_PM.png)
diff --git a/results/classifier/gemma3:12b/boot/380 b/results/classifier/gemma3:12b/boot/380
new file mode 100644
index 000000000..a6acd68fa
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/380
@@ -0,0 +1,2 @@
+
+Windows 7 fails to boot
diff --git a/results/classifier/gemma3:12b/boot/389 b/results/classifier/gemma3:12b/boot/389
new file mode 100644
index 000000000..37a174a65
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/389
@@ -0,0 +1,2 @@
+
+Add multiboot2 support
diff --git a/results/classifier/gemma3:12b/boot/393569 b/results/classifier/gemma3:12b/boot/393569
new file mode 100644
index 000000000..b143558b1
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/393569
@@ -0,0 +1,6 @@
+
+qemu cannot load multiple initramfs archives
+
+According to Documentation/early-userspace/buffer-format.txt, an initramfs can be populated from multiple cpio archives, which seems like it could be a really useful feature when using QEMU to boot Linux kernels directly, without installing them on the disk image.
+
+Unfortunately, QEMU does not support actually loading multiple files into the initrd space (which is also where initramfs archives go). It would be really nice if it did.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/425 b/results/classifier/gemma3:12b/boot/425
new file mode 100644
index 000000000..c4c5fca75
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/425
@@ -0,0 +1,2 @@
+
+QEMU prepends pathnames to command lines of Multiboot kernels and modules, contrary to the specification
diff --git a/results/classifier/gemma3:12b/boot/436 b/results/classifier/gemma3:12b/boot/436
new file mode 100644
index 000000000..c1995e670
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/436
@@ -0,0 +1,2 @@
+
+window 8 stuck during boot on Qemu
diff --git a/results/classifier/gemma3:12b/boot/444 b/results/classifier/gemma3:12b/boot/444
new file mode 100644
index 000000000..814267972
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/444
@@ -0,0 +1,2 @@
+
+EFI stub: ERROR: This 64 KB granular kernel is not supported by your CPU
diff --git a/results/classifier/gemma3:12b/boot/45 b/results/classifier/gemma3:12b/boot/45
new file mode 100644
index 000000000..4e60636d6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/45
@@ -0,0 +1,2 @@
+
+qemu-system-aarch64: no function defined to set boot device list for this architecture
diff --git a/results/classifier/gemma3:12b/boot/452 b/results/classifier/gemma3:12b/boot/452
new file mode 100644
index 000000000..a98579275
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/452
@@ -0,0 +1,57 @@
+
+Akita (and probably all Spitz-like / PXA270) platform does not load BIOS binary
+Description of problem:
+QEMU does not appear to load a binary file passed with the "-bios" argument for the "akita" target. This probably extends to other spitz-type systems.
+
+Exptected behavior: qemu loads the binary into address 0x0000.
+Actual behavior: address space at 0x0000 contains only zeros.
+Steps to reproduce:
+Terminal 1:
+```
+qemu-system-arm -M akita -bios c750.rom -s -S
+```
+
+Terminal 2: 
+```
+gdb-multiarch
+target remote localhost:1234
+x/64i $pc
+```
+
+Result:
+```
+=> 0x0: andeq   r0, r0, r0
+   0x4: andeq   r0, r0, r0
+   0x8: andeq   r0, r0, r0
+   0xc: andeq   r0, r0, r0
+   0x10:        andeq   r0, r0, r0
+```
+
+Correct behavior (can demonstrate with virt machine):
+Same as before, but start Terminal 1 with:
+```
+qemu-system-arm -M akita -bios c750.rom -s -S
+```
+
+Result:
+```
+=> 0x0: b       0x34
+   0x4: ldr     pc, [pc, #156]  ; 0xa8
+   0x8: ldr     pc, [pc, #156]  ; 0xac
+   0xc: ldr     pc, [pc, #156]  ; 0xb0
+   0x10:        ldr     pc, [pc, #156]  ; 0xb4
+   0x14:        nop                     ; (mov r0, r0)
+   0x18:        ldr     pc, [pc, #152]  ; 0xb8
+   0x1c:        ldr     pc, [pc, #152]  ; 0xbc
+   0x20:        mov     r0, #128        ; 0x80
+   0x24:        b       0x2c
+   0x28:        mov     r0, #129        ; 0x81
+   0x2c:        ldr     r1, [pc, #140]  ; 0xc0
+   0x30:        str     r0, [r1]
+   0x34:        mrs     lr, CPSR
+   0x38:        bic     lr, lr, #31
+   0x3c:        orr     lr, lr, #211    ; 0xd3
+   0x40:        msr     CPSR_fc, lr
+```
+Additional information:
+File with very tiny boot ROM: [c750-tiny.rom](/uploads/045852c8b353174bf0b7a4193d0d1be0/c750-tiny.rom)
diff --git a/results/classifier/gemma3:12b/boot/475 b/results/classifier/gemma3:12b/boot/475
new file mode 100644
index 000000000..ef0ce7813
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/475
@@ -0,0 +1,2 @@
+
+4.2 regression: ReactOS crashes on boot
diff --git a/results/classifier/gemma3:12b/boot/485239 b/results/classifier/gemma3:12b/boot/485239
new file mode 100644
index 000000000..24b273137
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/485239
@@ -0,0 +1,21 @@
+
+Windows 2008 datacenter- 64 bit , installation fails with qemu-system-x86_64 0.11.50
+
+Installation of Windows 2008 datacenter- 64 bit fails with qemu-system-x86_64. 
+Version of qemu-system-x86_64 is 0.11.50. 
+The installation source is dvd iso. Just after booting for installation of the Windows guest, it hangs for sometime and then the installation crashes with the error:
+
+"A problem has been detected and windows has been shut down to prevent damage to your computer".
+
+Below is the command used for creating the guest.
+/usr/local/bin/qemu-system-x86_64 -cdrom /home/en_windows_server_2008_datacenter_enterprise_standard_x64_dvd_X14-26714.iso -hda /var/lib/libvirt/images/win2008_dc_64.qcow2 -m 3000 -smp 3 -net nic -net tap,script=/home/qemu-ifup-latest -name win2008_dc_64 -vnc :1 &
+
+Disk info of the guest image is as below:
+/usr/local/bin/qemu-img info /var/lib/libvirt/images/win2008_dc_64.qcow2
+image: /var/lib/libvirt/images/win2008_dc_64.qcow2
+file format: qcow2
+virtual size: 15G (16106127360 bytes)
+disk size: 136K
+cluster_size: 65536
+
+This issue is also reproducible with raw image format.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/499 b/results/classifier/gemma3:12b/boot/499
new file mode 100644
index 000000000..c9ac820cb
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/499
@@ -0,0 +1,2 @@
+
+booting a linux guest with qemu-system-sparc with icount enabled hangs
diff --git a/results/classifier/gemma3:12b/boot/513 b/results/classifier/gemma3:12b/boot/513
new file mode 100644
index 000000000..6ced9a17a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/513
@@ -0,0 +1,2 @@
+
+Qemu/WHPX fails on applying UEFI firmware with -pflash
diff --git a/results/classifier/gemma3:12b/boot/551545 b/results/classifier/gemma3:12b/boot/551545
new file mode 100644
index 000000000..7b2423600
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/551545
@@ -0,0 +1,96 @@
+
+PXE netboot not booting localboot from virtio-disk
+
+Binary package hint: qemu-kvm
+
+lsb_release -rd
+Description:	Ubuntu lucid (development branch)
+Release:	10.04
+
+apt-cache policy qemu-kvm
+qemu-kvm:
+  Installiert: 0.12.3+noroms-0ubuntu3
+  Kandidat: 0.12.3+noroms-0ubuntu3
+  Versions-Tabelle:
+ *** 0.12.3+noroms-0ubuntu3 0
+        500 http://intranet/ubuntu/ lucid/main Packages
+        100 /var/lib/dpkg/status
+
+Description of the problem:
+
+Starting a guest like this:
+
+vdekvm \
+  -m 256M \
+  -cpu host \
+  -smp 1 \
+  -name karmic \
+  -boot order=nc \
+  -drive file=/dev/vg01/test,if=virtio,boot=on,cache=none \
+  -net nic,vlan=0,macaddr=00:2f:8d:b6:cf:d0,model=virtio \
+  -net vde,vlan=0,sock=/var/run/vde2/vde0.ctl \
+  -watchdog i6300esb \
+  -vnc :0 \
+  -serial telnet:localhost:23,server,nowait \
+  -monitor tcp:127.0.0.1:12000,server,nowait \
+  -runas kvmguest
+
+On "telnet localhost" you can see that the following boot-menu appears:
+
+- Boot Menu -
+=============
+
+local
+rescue
+
+It is loaded from this pxelinux.cfg/default file:
+
+SERIAL 0 9600n8
+
+DISPLAY boot.txt
+
+TIMEOUT 120
+DEFAULT local
+PROMPT 1
+
+LABEL local
+	localboot 0
+
+LABEL rescue
+	kernel lucid
+	append initrd=lucid-initrd.gz rescue/enable=true -- quiet console=ttyS0,9600n8
+
+
+After the timeout, the guest tries to boot, but fails and reloads the boot menu. This is an endless loop, until I break it or choose the rescue menu entry.
+
+I would expect that it boots from first virtio-disk
+
+ProblemType: Bug
+DistroRelease: Ubuntu 10.04
+Package: qemu-kvm 0.12.3+noroms-0ubuntu3
+ProcVersionSignature: Ubuntu 2.6.32-18.27-generic 2.6.32.10+drm33.1
+Uname: Linux 2.6.32-18-generic x86_64
+Architecture: amd64
+Date: Tue Mar 30 11:40:59 2010
+ExecutablePath: /usr/bin/qemu-system-x86_64
+MachineType: MICRO-STAR INTERANTIONAL CO.,LTD MS-7368
+ProcCmdLine: root=UUID=0d27271c-feaa-40d9-bbbd-baff4ca1d3cc rw init=/bin/bash
+ProcEnviron:
+ LANG=de_DE.UTF-8
+ SHELL=/bin/bash
+SourcePackage: qemu-kvm
+dmi.bios.date: 10/31/2007
+dmi.bios.vendor: American Megatrends Inc.
+dmi.bios.version: V1.5B2
+dmi.board.asset.tag: To Be Filled By O.E.M.
+dmi.board.name: MS-7368
+dmi.board.vendor: MICRO-STAR INTERANTIONAL CO.,LTD
+dmi.board.version: 1.0
+dmi.chassis.asset.tag: To Be Filled By O.E.M.
+dmi.chassis.type: 3
+dmi.chassis.vendor: To Be Filled By O.E.M.
+dmi.chassis.version: To Be Filled By O.E.M.
+dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV1.5B2:bd10/31/2007:svnMICRO-STARINTERANTIONALCO.,LTD:pnMS-7368:pvr1.0:rvnMICRO-STARINTERANTIONALCO.,LTD:rnMS-7368:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
+dmi.product.name: MS-7368
+dmi.product.version: 1.0
+dmi.sys.vendor: MICRO-STAR INTERANTIONAL CO.,LTD
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/586175 b/results/classifier/gemma3:12b/boot/586175
new file mode 100644
index 000000000..f7c188f7d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/586175
@@ -0,0 +1,13 @@
+
+Windows XP/2003 doesn't boot
+
+Hello everyone,
+
+my qemu doesn't boot any Windows XP/2003 installations if I try to boot the image.
+If I boot the install cd first, it's boot manager counts down and triggers the boot on it's own. That's kinda stupid.
+
+I'm using libvirt, but even by a simple
+> qemu-kvm -drive file=image.img,media=disk,if=ide,boot=on
+it won't boot. Qemu hangs at the message "Booting from Hard Disk..."
+
+I'm using qemu-kvm-0.12.4 with SeaBIOS 0.5.1 on Gentoo (No-Multilib and AMD64). It's a server, that means I'm using VNC as the primary graphic output but i don't think it should be an issue.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/588731 b/results/classifier/gemma3:12b/boot/588731
new file mode 100644
index 000000000..a0f857751
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/588731
@@ -0,0 +1,29 @@
+
+PXE boot not working
+
+/root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -boot n -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor
+
+
+
+net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)                                                                                               
+ [Link:up, TX:0 TXE:0 RX:0 RXE:0]                                                                                                         
+ DHCP (net0 02:5a:3b:27:00:a1)................ Connection timed out (0x4c106035)                                                            
+ No more network devices                                                                                                                    
+                                                                                                                                                                                                     
+No bootable device. 
+
+
+
+After doing a system_reset ....
+
+net0: 02:5a:3b:27:00:a1 on PCI00:03.0 (open)                                                                                               
+ [Link:up, TX:0 TXE:0 RX:0 RXE:0]                                                                                                         
+DHCP (net0 02:5a:3b:27:00:a1).... ok                                                                                                       
+net0: 10.201.1.161/255.0.0.0 gw 10.0.0.1                                                                                                   
+Booting from filename "boot.pxe"                                                                                                          
+tftp://x.x.x./boot.pxe.. ok      
+
+
+And it magaically works.
+
+using HEAD.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/588748 b/results/classifier/gemma3:12b/boot/588748
new file mode 100644
index 000000000..55d9b38f3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/588748
@@ -0,0 +1,4 @@
+
+QEMU fails to boot DR DOS Plus since 0.6.1
+
+The commit in r1049 (serial interrupt fix (Hampa Hug)) prevents booting Digital Research DOS Plus.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/598 b/results/classifier/gemma3:12b/boot/598
new file mode 100644
index 000000000..27c918c94
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/598
@@ -0,0 +1,2 @@
+
+QEMU boot kernel for ppc e300c3 problem
diff --git a/results/classifier/gemma3:12b/boot/599 b/results/classifier/gemma3:12b/boot/599
new file mode 100644
index 000000000..db11c3096
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/599
@@ -0,0 +1,12 @@
+
+Q35: Windows BSOD running on 6.1.0
+Description of problem:
+Starting with QEMU 6.1.0, Windows no longer boots with Q35 (including `pc-q35-6.0` as well). When booting an existing Windows 7 installation, BSOD appears during boot (0x0000007B). If you try to install Windows from an ISO, the follow error appears when you try to start setup.
+
+![Screen_Shot_2021-09-05_at_1.58.05_PM](/uploads/cfa04f25e9a8dc5ca8f201c87794b6c7/Screen_Shot_2021-09-05_at_1.58.05_PM.png)
+
+Other people also reported similar issues booting Windows 10, as well as during use of Windows XP.
+Steps to reproduce:
+Enter commands from above.
+Additional information:
+This was not an issue in QEMU 6.0.0. I can reproduce it at `master`.
diff --git a/results/classifier/gemma3:12b/boot/618533 b/results/classifier/gemma3:12b/boot/618533
new file mode 100644
index 000000000..e2fb3c6ba
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/618533
@@ -0,0 +1,28 @@
+
+OpenSolaris guest fails to see the Solaris partitions of a physical disk in qemu-kvm-9999 (GIT)
+
+# qemu-kvm --version
+QEMU emulator version 0.13.50 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard
+
+The following disk is presented to guest as IDE disk with /dev/sdd as path.
+
+# fdisk -l /dev/sdd
+
+Disk /dev/sdd: 750.2 GB, 750156374016 bytes
+255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
+Units = sectors of 1 * 512 = 512 bytes
+Sector size (logical/physical): 512 bytes / 512 bytes
+I/O size (minimum/optimal): 512 bytes / 512 bytes
+Disk identifier: 0x7f3a03aa
+
+   Device Boot      Start         End      Blocks   Id  System
+/dev/sdd1              63     7887914     3943926   1b  Hidden W95 FAT32
+/dev/sdd2         7887915   980736119   486424102+  83  Linux
+/dev/sdd3   *   980736120  1083150494    51207187+  bf  Solaris
+/dev/sdd4      1083150495  1465144064   190996785    5  Extended
+/dev/sdd5      1083150558  1107746009    12297726   83  Linux
+/dev/sdd6      1107746073  1465144064   178698996    7  HPFS/NTFS
+
+The prtvtoc output is attached from both VirtualBox and Qemu-KVM. As can be seen in the screenshots, a valid Solaris partition table (which is inside the /dev/sdd3, marked 'bf' in Linux fdisk output) is not seen in Qemu but seen in Virtualbox.
+
+This makes the guest unbootable in Qemu because the root FS is not found but its bootable in Virtualbox.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/622 b/results/classifier/gemma3:12b/boot/622
new file mode 100644
index 000000000..c79d6365a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/622
@@ -0,0 +1,2 @@
+
+Mac OS X Cheetah Virtual Machine booting back into Mac OS 9 for no reason
diff --git a/results/classifier/gemma3:12b/boot/624 b/results/classifier/gemma3:12b/boot/624
new file mode 100644
index 000000000..a8d8150b0
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/624
@@ -0,0 +1,338 @@
+
+powerpc: halt and reboot via firmware via cuda fail
+Description of problem:
+Both shutdown and reboot cause errors preventing the action from occuring. With logging turned on as above, it can be seen that the issue is with CUDA. If the option `-M mac99,via=pmu` is given the action happens as expected.
+
+```
+# qemu-system-ppc -trace 'cuda_*' -d unimp,guest_errors -serial file:/dev/stdout -hda /tmp/grub-shell.CdAU68FI6P/grub.iso -boot c
+WARNING: Image format was not specified for '/tmp/grub-shell.CdAU68FI6P/grub.iso' and probing guessed raw.
+         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
+         Specify the 'raw' format explicitly to remove the restrictions.
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x00
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x1f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x1f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x1f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x1f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x2f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x2f
+cuda_packet_send length 4
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x02
+cuda_packet_send_data [3] 0x01
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x01
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x2b
+cuda_delay_set_sr_int
+cuda_data_send send: 0x28
+cuda_delay_set_sr_int
+cuda_data_send send: 0xfe
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 4
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x2b
+cuda_packet_receive_data [2] 0x28
+cuda_packet_receive_data [3] 0xfe
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x2b
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x2b
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x81
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x81
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x81
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x81
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x2f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x2f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x2f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x2f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x3f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x3f
+cuda_packet_send length 4
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x03
+cuda_packet_send_data [3] 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x03
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x3b
+cuda_delay_set_sr_int
+cuda_data_send send: 0x29
+cuda_delay_set_sr_int
+cuda_data_send send: 0xfe
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 4
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x3b
+cuda_packet_receive_data [2] 0x29
+cuda_packet_receive_data [3] 0xfe
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x3b
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x3b
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x91
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x91
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x00
+cuda_packet_send_data [2] 0x91
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x91
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x3f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x3f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x3f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x3f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x4f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x4f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x4f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x4f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x5f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x5f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x5f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x5f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_data_send send: 0x00
+cuda_delay_set_sr_int
+cuda_data_send send: 0x7f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 2
+cuda_packet_receive_data [0] 0x00
+cuda_packet_receive_data [1] 0x7f
+cuda_packet_send length 3
+cuda_packet_send_data [0] 0x00
+cuda_packet_send_data [1] 0x02
+cuda_packet_send_data [2] 0x7f
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x00
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x7f
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+
+>> =============================================================
+>> OpenBIOS 1.1 [Aug 12 2021 13:35]
+>> Configuration device id QEMU version 1 machine id 2
+>> CPUs: 1
+>> Memory: 128M
+>> UUID: 00000000-0000-0000-0000-000000000000
+>> CPU type PowerPC,750
+milliseconds isn't unique.
+>> switching to new context:
+>> call-method block-size failed with error ffffffdf
+>> call-method block-size failed with error ffffffdf
+cuda_data_send send: 0x01
+cuda_delay_set_sr_int
+cuda_data_send send: 0x0a
+cuda_delay_set_sr_int
+cuda_data_send send: 0xfa
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+cuda_packet_receive length 3
+cuda_packet_receive_data [0] 0x01
+cuda_packet_receive_data [1] 0x0a
+cuda_packet_receive_data [2] 0xfa
+cuda_receive_packet_cmd handling command POWERDOWN
+CUDA: POWERDOWN: wrong parameters 2
+cuda_packet_send length 4
+cuda_packet_send_data [0] 0x02
+cuda_packet_send_data [1] 0x05
+cuda_packet_send_data [2] 0x01
+cuda_packet_send_data [3] 0x0a
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x02
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x05
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x01
+cuda_delay_set_sr_int
+cuda_data_recv recv: 0x0a
+cuda_delay_set_sr_int
+cuda_delay_set_sr_int
+>> interpret shut-down failed with error ffffffed
+>> interpret poweroff failed with error ffffffed
+```
+Steps to reproduce:
+1. Download attached iso file: [grub.iso.xz](/uploads/dea8f2bde4d90b9928f54bb9b73d76e9/grub.iso.xz)
+2. Decompress iso
+3. Run qemu as specified above
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/627 b/results/classifier/gemma3:12b/boot/627
new file mode 100644
index 000000000..effc7ce3a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/627
@@ -0,0 +1,8 @@
+
+VI.EXE crashes on start under QEMU; works under BOCHS
+Description of problem:
+vi.exe hangs on startup; can be verified to work in bochs
+Steps to reproduce:
+1. Run vi.exe from DOS prompt; hang is evident immediately as ~ ~ ~ ~ doesn't show up
+Additional information:
+Actual [vi.exe](/uploads/d77076b8187489253c6ad8f1ab3ec247/vi.exe) attached; it's ridiculously old; the kind of thing that belongs on archive.org; I think I actually own this copy program by inheritance; but if the copyright holder objects we'll have to take it down again. :(
diff --git a/results/classifier/gemma3:12b/boot/636 b/results/classifier/gemma3:12b/boot/636
new file mode 100644
index 000000000..410ffecc6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/636
@@ -0,0 +1,357 @@
+
+tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd can not perform graceful shutdown
+Description of problem:
+Roughly once every 20 times, the [`halt`](https://gitlab.com/qemu-project/qemu/-/blob/73257aa02376829f724357094e252fc3e5dd1363/tests/acceptance/boot_linux_console.py#L522) command will not produce the desired effect, and [wait()ing](https://gitlab.com/qemu-project/qemu/-/blob/73257aa02376829f724357094e252fc3e5dd1363/tests/acceptance/boot_linux_console.py#L524) on the QEMU process to gracefully shutdown will fail.
+
+I was not able to see any other failure in what the test covers, except the `halt` command and the `wait()`ing.  That is, the booting of the kernel and initrd, and the execution of commands to inspect the system all run without problems.
+Steps to reproduce:
+1. make check-venv
+2. ./tests/venv/bin/avocado run tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd
+Additional information:
+```
+13:48:01 DEBUG| PARAMS (key=arch, path=*, default=arm) => 'arm'
+13:48:01 DEBUG| PARAMS (key=cpu, path=*, default=None) => None
+13:48:01 DEBUG| PARAMS (key=machine, path=*, default=raspi2b) => 'raspi2b'
+13:48:01 DEBUG| PARAMS (key=qemu_bin, path=*, default=./qemu-system-arm) => './qemu-system-arm'
+13:48:01 DEBUG| Test workdir initialized at: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd
+13:48:08 DEBUG| QEMUMachine "default" created
+13:48:08 DEBUG| QEMUMachine "default" temp_dir: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/qemu-machine-5pavn9gy
+13:48:08 DEBUG| QEMUMachine "default" log_dir: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd
+13:48:08 DEBUG| VM launch command: './qemu-system-arm -display none -vga none -chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock -mon chardev=mon,mode=control -machine raspi2b -chardev socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off -serial chardev:console -kernel /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img -dtb /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb -initrd /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio -append printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0 -no-reboot'
+13:48:08 DEBUG| >>> {'execute': 'qmp_capabilities'}
+13:48:08 DEBUG| <<< {'return': {}}
+13:48:08 DEBUG| [    0.000000] Booting Linux on physical CPU 0xf00
+13:48:08 DEBUG| [    0.000000] Linux version 4.14.98-v7+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1200 SMP Tue Feb 12 20:27:48 GMT 2019
+13:48:08 DEBUG| [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
+13:48:08 DEBUG| [    0.000000] CPU: div instructions available: patching division code
+13:48:08 DEBUG| [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
+13:48:08 DEBUG| [    0.000000] OF: fdt: Machine model: Raspberry Pi 2 Model B
+13:48:08 DEBUG| [    0.000000] earlycon: pl11 at MMIO 0x3f201000 (options '')
+13:48:08 DEBUG| [    0.000000] bootconsole [pl11] enabled
+13:48:08 DEBUG| [    0.000000] Memory policy: Data cache writealloc
+13:48:08 DEBUG| [    0.000000] cma: Reserved 8 MiB at 0x3b800000
+13:48:08 DEBUG| [    0.000000] percpu: Embedded 17 pages/cpu @baf2e000 s38720 r8192 d22720 u69632
+13:48:08 DEBUG| [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 243600
+13:48:08 DEBUG| [    0.000000] Kernel command line: printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0
+13:48:08 DEBUG| PID hash table entries: 4096 (order: 2, 16384 bytes)
+13:48:08 DEBUG| Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
+13:48:08 DEBUG| Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
+13:48:08 DEBUG| Memory: 949120K/983040K available (7168K kernel code, 577K rwdata, 2080K rodata, 1024K init, 698K bss, 25728K reserved, 8192K cma-reserved)
+13:48:08 DEBUG| Virtual kernel memory layout:
+13:48:08 DEBUG| vector  : 0xffff0000 - 0xffff1000   (   4 kB)
+13:48:08 DEBUG| fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
+13:48:08 DEBUG| vmalloc : 0xbc800000 - 0xff800000   (1072 MB)
+13:48:08 DEBUG| lowmem  : 0x80000000 - 0xbc000000   ( 960 MB)
+13:48:08 DEBUG| modules : 0x7f000000 - 0x80000000   (  16 MB)
+13:48:08 DEBUG| .text : 0x80008000 - 0x80800000   (8160 kB)
+13:48:08 DEBUG| .init : 0x80b00000 - 0x80c00000   (1024 kB)
+13:48:08 DEBUG| .data : 0x80c00000 - 0x80c906d4   ( 578 kB)
+13:48:08 DEBUG| .bss : 0x80c97ef8 - 0x80d468f0   ( 699 kB)
+13:48:08 DEBUG| SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
+13:48:08 DEBUG| ftrace: allocating 25298 entries in 75 pages
+13:48:09 DEBUG| Hierarchical RCU implementation.
+13:48:09 DEBUG| NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
+13:48:09 DEBUG| arch_timer: cp15 timer(s) running at 62.50MHz (virt).
+13:48:09 DEBUG| clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
+13:48:09 DEBUG| sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
+13:48:09 DEBUG| Switching to timer-based delay loop, resolution 16ns
+13:48:09 DEBUG| Console: colour dummy device 80x30
+13:48:09 DEBUG| Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000)
+13:48:09 DEBUG| pid_max: default: 32768 minimum: 301
+13:48:09 DEBUG| Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
+13:48:09 DEBUG| Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
+13:48:09 DEBUG| Disabling memory control group subsystem
+13:48:09 DEBUG| CPU: Testing write buffer coherency: ok
+13:48:09 DEBUG| CPU0: update cpu_capacity 1024
+13:48:09 DEBUG| CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
+13:48:09 DEBUG| Setting up static identity map for 0x100000 - 0x10003c
+13:48:09 DEBUG| Hierarchical SRCU implementation.
+13:48:09 DEBUG| smp: Bringing up secondary CPUs ...
+13:48:09 DEBUG| CPU1: update cpu_capacity 1024
+13:48:09 DEBUG| CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01
+13:48:09 DEBUG| CPU2: update cpu_capacity 1024
+13:48:09 DEBUG| CPU2: thread -1, cpu 2, socket 15, mpidr 80000f02
+13:48:09 DEBUG| CPU3: update cpu_capacity 1024
+13:48:09 DEBUG| CPU3: thread -1, cpu 3, socket 15, mpidr 80000f03
+13:48:09 DEBUG| smp: Brought up 1 node, 4 CPUs
+13:48:09 DEBUG| SMP: Total of 4 processors activated (500.00 BogoMIPS).
+13:48:09 DEBUG| CPU: All CPU(s) started in SVC mode.
+13:48:09 DEBUG| devtmpfs: initialized
+13:48:09 DEBUG| random: get_random_u32 called from bucket_table_alloc+0xfc/0x24c with crng_init=0
+13:48:09 DEBUG| VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
+13:48:09 DEBUG| clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
+13:48:09 DEBUG| futex hash table entries: 1024 (order: 4, 65536 bytes)
+13:48:09 DEBUG| pinctrl core: initialized pinctrl subsystem
+13:48:09 DEBUG| NET: Registered protocol family 16
+13:48:09 DEBUG| DMA: preallocated 1024 KiB pool for atomic coherent allocations
+13:48:09 DEBUG| hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
+13:48:09 DEBUG| hw-breakpoint: maximum watchpoint size is 8 bytes.
+13:48:09 DEBUG| Serial: AMBA PL011 UART driver
+13:48:09 DEBUG| bcm2835-mbox 3f00b880.mailbox: mailbox enabled
+13:48:09 DEBUG| bcm2835-dma 3f007000.dma: DMA legacy API manager at bc813000, dmachans=0x1
+13:48:09 DEBUG| SCSI subsystem initialized
+13:48:09 DEBUG| usbcore: registered new interface driver usbfs
+13:48:09 DEBUG| usbcore: registered new interface driver hub
+13:48:09 DEBUG| usbcore: registered new device driver usb
+13:48:09 DEBUG| raspberrypi-firmware soc:firmware: Attached to firmware from 1970-01-05 00:12
+13:48:09 DEBUG| clocksource: Switched to clocksource arch_sys_counter
+13:48:09 DEBUG| VFS: Disk quotas dquot_6.6.0
+13:48:09 DEBUG| VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
+13:48:09 DEBUG| FS-Cache: Loaded
+13:48:09 DEBUG| CacheFiles: Loaded
+13:48:09 DEBUG| NET: Registered protocol family 2
+13:48:09 DEBUG| TCP established hash table entries: 8192 (order: 3, 32768 bytes)
+13:48:09 DEBUG| TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
+13:48:09 DEBUG| TCP: Hash tables configured (established 8192 bind 8192)
+13:48:09 DEBUG| UDP hash table entries: 512 (order: 2, 16384 bytes)
+13:48:09 DEBUG| UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
+13:48:09 DEBUG| NET: Registered protocol family 1
+13:48:09 DEBUG| RPC: Registered named UNIX socket transport module.
+13:48:09 DEBUG| RPC: Registered udp transport module.
+13:48:09 DEBUG| RPC: Registered tcp transport module.
+13:48:09 DEBUG| RPC: Registered tcp NFSv4.1 backchannel transport module.
+13:48:09 DEBUG| Trying to unpack rootfs image as initramfs...
+13:48:09 DEBUG| Freeing initrd memory: 3256K
+13:48:09 DEBUG| hw perfevents: enabled with armv7_cortex_a7 PMU driver, 5 counters available
+13:48:09 DEBUG| workingset: timestamp_bits=14 max_order=18 bucket_order=4
+13:48:09 DEBUG| FS-Cache: Netfs 'nfs' registered for caching
+13:48:09 DEBUG| NFS: Registering the id_resolver key type
+13:48:09 DEBUG| Key type id_resolver registered
+13:48:09 DEBUG| Key type id_legacy registered
+13:48:09 DEBUG| nfs4filelayout_init: NFSv4 File Layout Driver Registering...
+13:48:09 DEBUG| Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
+13:48:09 DEBUG| io scheduler noop registered
+13:48:09 DEBUG| io scheduler deadline registered
+13:48:09 DEBUG| io scheduler cfq registered (default)
+13:48:09 DEBUG| io scheduler mq-deadline registered
+13:48:09 DEBUG| io scheduler kyber registered
+13:48:09 DEBUG| BCM2708FB: allocated DMA memory fb900000
+13:48:09 DEBUG| BCM2708FB: allocated DMA channel 0 @ bc813000
+13:48:09 DEBUG| Console: switching to colour frame buffer device 100x30
+13:48:09 DEBUG| bcm2835-rng 3f104000.rng: hwrng registered
+13:48:09 DEBUG| vc-mem: phys_addr:0x00000000 mem_base=0x00000000 mem_size:0x00000000(0 MiB)
+13:48:09 DEBUG| vc-sm: Videocore shared memory driver
+13:48:09 DEBUG| gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
+13:48:09 DEBUG| brd: module loaded
+13:48:09 DEBUG| loop: module loaded
+13:48:09 DEBUG| Loading iSCSI transport class v2.0-870.
+13:48:09 DEBUG| libphy: Fixed MDIO Bus: probed
+13:48:09 DEBUG| usbcore: registered new interface driver lan78xx
+13:48:09 DEBUG| usbcore: registered new interface driver smsc95xx
+13:48:09 DEBUG| dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
+13:48:09 DEBUG| dwc_otg 3f980000.usb: base=0xf0980000
+13:48:10 DEBUG| Core Release: 2.94a
+13:48:10 DEBUG| Setting default values for core params
+13:48:10 DEBUG| Finished setting default values for core params
+13:48:10 DEBUG| Using Buffer DMA mode
+13:48:10 DEBUG| Periodic Transfer Interrupt Enhancement - disabled
+13:48:10 DEBUG| Multiprocessor Interrupt Enhancement - disabled
+13:48:10 DEBUG| OTG VER PARAM: 0, OTG VER FLAG: 0
+13:48:10 DEBUG| Shared Tx FIFO mode
+13:48:10 DEBUG| WARN::dwc_otg_hcd_init:1046: FIQ DMA bounce buffers: virt = 0xbb914000 dma = 0xfb914000 len=9024
+13:48:10 DEBUG| WARN::hcd_init_fiq:459: FIQ on core 1 at 0x805edb88
+13:48:10 DEBUG| WARN::hcd_init_fiq:460: FIQ ASM at 0x805edcb4 length 36
+13:48:10 DEBUG| WARN::hcd_init_fiq:486: MPHI regs_base at 0xf0006000
+13:48:10 DEBUG| dwc_otg 3f980000.usb: DWC OTG Controller
+13:48:10 DEBUG| dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
+13:48:10 DEBUG| dwc_otg 3f980000.usb: irq 62, io mem 0x00000000
+13:48:10 DEBUG| Init: Port Power? op_state=1
+13:48:10 DEBUG| Init: Power Port (1)
+13:48:10 DEBUG| usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
+13:48:10 DEBUG| usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
+13:48:10 DEBUG| usb usb1: Product: DWC OTG Controller
+13:48:10 DEBUG| usb usb1: Manufacturer: Linux 4.14.98-v7+ dwc_otg_hcd
+13:48:10 DEBUG| usb usb1: SerialNumber: 3f980000.usb
+13:48:10 DEBUG| hub 1-0:1.0: USB hub found
+13:48:10 DEBUG| hub 1-0:1.0: 1 port detected
+13:48:10 DEBUG| usbcore: registered new interface driver usb-storage
+13:48:10 DEBUG| mousedev: PS/2 mouse device common for all mice
+13:48:10 DEBUG| IR NEC protocol handler initialized
+13:48:10 DEBUG| IR RC5(x/sz) protocol handler initialized
+13:48:10 DEBUG| IR RC6 protocol handler initialized
+13:48:10 DEBUG| IR JVC protocol handler initialized
+13:48:10 DEBUG| IR Sony protocol handler initialized
+13:48:10 DEBUG| IR SANYO protocol handler initialized
+13:48:10 DEBUG| IR Sharp protocol handler initialized
+13:48:10 DEBUG| IR MCE Keyboard/mouse protocol handler initialized
+13:48:10 DEBUG| IR XMP protocol handler initialized
+13:48:10 DEBUG| bcm2835-wdt 3f100000.watchdog: Broadcom BCM2835 watchdog timer
+13:48:10 DEBUG| bcm2835-cpufreq: min=700000 max=700000
+13:48:10 DEBUG| sdhci: Secure Digital Host Controller Interface driver
+13:48:10 DEBUG| sdhci: Copyright(c) Pierre Ossman
+13:48:10 DEBUG| sdhost-bcm2835 3f202000.mmc: could not get clk, deferring probe
+13:48:10 DEBUG| sdhci-pltfm: SDHCI platform and OF driver helper
+13:48:10 DEBUG| ledtrig-cpu: registered to indicate activity on CPUs
+13:48:10 DEBUG| hidraw: raw HID events driver (C) Jiri Kosina
+13:48:10 DEBUG| usbcore: registered new interface driver usbhid
+13:48:10 DEBUG| usbhid: USB HID core driver
+13:48:10 DEBUG| vchiq: vchiq_init_state: slot_zero = bb980000, is_master = 0
+13:48:10 DEBUG| bcm2835_vchiq 3f00b840.vchiq: failed to set channelbase
+13:48:10 DEBUG| vchiq: could not load vchiq
+13:48:10 DEBUG| Initializing XFRM netlink socket
+13:48:10 DEBUG| NET: Registered protocol family 17
+13:48:10 DEBUG| Key type dns_resolver registered
+13:48:10 DEBUG| Registering SWP/SWPB emulation handler
+13:48:10 DEBUG| registered taskstats version 1
+13:48:10 DEBUG| uart-pl011 3f201000.serial: cts_event_workaround enabled
+13:48:10 DEBUG| 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
+13:48:10 DEBUG| console [ttyAMA0] enabled
+13:48:10 DEBUG| console [ttyAMA0] enabled
+13:48:10 DEBUG| bootconsole [pl11] disabled
+13:48:10 DEBUG| bootconsole [pl11] disabled
+13:48:10 DEBUG| bcm2835_thermal 3f212000.thermal: Not able to read trip_temp: -33
+13:48:10 DEBUG| bcm2835-clk 3f101000.cprman: tsens: couldn't lock PLL
+13:48:10 DEBUG| bcm2835_thermal: probe of 3f212000.thermal failed with error -33
+13:48:10 DEBUG| sdhost: log_buf @ bb913000 (fb913000)
+13:48:10 DEBUG| mmc0: sdhost-bcm2835 loaded - DMA enabled (>1)
+13:48:10 DEBUG| of_cfs_init
+13:48:10 DEBUG| of_cfs_init: OK
+13:48:10 DEBUG| uart-pl011 3f201000.serial: no DMA platform data
+13:48:10 DEBUG| Freeing unused kernel memory: 1024K
+13:48:11 DEBUG| mount: mounting devtmpfs on /dev failed: Device or resource busy
+13:48:11 DEBUG| Starting logging: OK
+13:48:11 DEBUG| Initializing random number generator... random: dd: uninitialized urandom read (512 bytes read)
+13:48:11 DEBUG| done.
+13:48:12 DEBUG| Starting network: OK
+13:48:12 DEBUG| Found console ttyAMA0
+13:48:12 DEBUG| Linux version 4.14.98-v7+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1200 SMP Tue Feb 12 20:27:48 GMT 2019
+13:48:12 DEBUG| Boot successful.
+13:48:12 DEBUG| cat /proc/cpuinfo
+13:48:12 DEBUG| / # cat /proc/cpuinfo
+13:48:12 DEBUG| processor	: 0
+13:48:12 DEBUG| model name	: ARMv7 Processor rev 5 (v7l)
+13:48:12 DEBUG| BogoMIPS	: 125.00
+13:48:12 DEBUG| Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+13:48:12 DEBUG| CPU implementer	: 0x41
+13:48:12 DEBUG| CPU architecture: 7
+13:48:12 DEBUG| CPU variant	: 0x0
+13:48:12 DEBUG| CPU part	: 0xc07
+13:48:12 DEBUG| CPU revision	: 5
+13:48:12 DEBUG| processor	: 1
+13:48:12 DEBUG| model name	: ARMv7 Processor rev 5 (v7l)
+13:48:12 DEBUG| BogoMIPS	: 125.00
+13:48:12 DEBUG| Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+13:48:12 DEBUG| CPU implementer	: 0x41
+13:48:12 DEBUG| CPU architecture: 7
+13:48:12 DEBUG| CPU variant	: 0x0
+13:48:12 DEBUG| CPU part	: 0xc07
+13:48:12 DEBUG| CPU revision	: 5
+13:48:12 DEBUG| processor	: 2
+13:48:12 DEBUG| model name	: ARMv7 Processor rev 5 (v7l)
+13:48:12 DEBUG| BogoMIPS	: 125.00
+13:48:12 DEBUG| Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+13:48:12 DEBUG| CPU implementer	: 0x41
+13:48:12 DEBUG| CPU architecture: 7
+13:48:12 DEBUG| CPU variant	: 0x0
+13:48:12 DEBUG| CPU part	: 0xc07
+13:48:12 DEBUG| CPU revision	: 5
+13:48:12 DEBUG| processor	: 3
+13:48:12 DEBUG| model name	: ARMv7 Processor rev 5 (v7l)
+13:48:12 DEBUG| BogoMIPS	: 125.00
+13:48:12 DEBUG| Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+13:48:12 DEBUG| CPU implementer	: 0x41
+13:48:12 DEBUG| CPU architecture: 7
+13:48:12 DEBUG| CPU variant	: 0x0
+13:48:12 DEBUG| CPU part	: 0xc07
+13:48:12 DEBUG| CPU revision	: 5
+13:48:12 DEBUG| Hardware	: BCM2835
+13:48:12 DEBUG| Revision	: 0000
+13:48:12 DEBUG| Serial		: 0000000000000000
+13:48:12 DEBUG| cat /proc/iomem
+13:48:12 DEBUG| / # cat /proc/iomem
+13:48:12 DEBUG| 00000000-3bffffff : System RAM
+13:48:12 DEBUG| 00008000-00afffff : Kernel code
+13:48:12 DEBUG| 00c00000-00d468ef : Kernel data
+13:48:12 DEBUG| 3f006000-3f006fff : dwc_otg
+13:48:12 DEBUG| 3f007000-3f007eff : /soc/dma@7e007000
+13:48:12 DEBUG| 3f00b880-3f00b8bf : /soc/mailbox@7e00b880
+13:48:12 DEBUG| 3f100000-3f100027 : /soc/watchdog@7e100000
+13:48:12 DEBUG| 3f101000-3f102fff : /soc/cprman@7e101000
+13:48:12 DEBUG| 3f200000-3f2000b3 : /soc/gpio@7e200000
+13:53:12 WARNI| qemu received signal 9; command: "./qemu-system-arm -display none -vga none -chardev socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock -mon chardev=mon,mode=control -machine raspi2b -chardev socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off -serial chardev:console -kernel /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img -dtb /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb -initrd /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio -append printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0 -no-reboot"
+13:53:12 ERROR| 
+13:53:12 ERROR| Reproduced traceback from: /var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py:794
+13:53:12 ERROR| Traceback (most recent call last):
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 514, in _do_shutdown
+13:53:12 ERROR|     self._soft_shutdown(timeout, has_quit)
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 497, in _soft_shutdown
+13:53:12 ERROR|     self._subp.wait(timeout=timeout)
+13:53:12 ERROR|   File "/usr/lib64/python3.9/subprocess.py", line 1189, in wait
+13:53:12 ERROR|     return self._wait(timeout=timeout)
+13:53:12 ERROR|   File "/usr/lib64/python3.9/subprocess.py", line 1909, in _wait
+13:53:12 ERROR|     raise TimeoutExpired(self.args, timeout)
+13:53:12 ERROR| subprocess.TimeoutExpired: Command '('./qemu-system-arm', '-display', 'none', '-vga', 'none', '-chardev', 'socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock', '-mon', 'chardev=mon,mode=control', '-machine', 'raspi2b', '-chardev', 'socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off', '-serial', 'chardev:console', '-kernel', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img', '-dtb', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb', '-initrd', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio', '-append', 'printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0', '-no-reboot')' timed out after 300 seconds
+13:53:12 ERROR| 
+13:53:12 ERROR| The above exception was the direct cause of the following exception:
+13:53:12 ERROR| 
+13:53:12 ERROR| Traceback (most recent call last):
+13:53:12 ERROR|   File "/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 502, in test_arm_raspi2_initrd
+13:53:12 ERROR|     self.vm.wait(300)
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 561, in wait
+13:53:12 ERROR|     self.shutdown(has_quit=True, timeout=timeout)
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 544, in shutdown
+13:53:12 ERROR|     self._do_shutdown(timeout, has_quit)
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 517, in _do_shutdown
+13:53:12 ERROR|     raise AbnormalShutdown("Could not perform graceful shutdown") \
+13:53:12 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown
+13:53:12 ERROR| 
+13:53:12 DEBUG| Local variables:
+13:53:12 DEBUG|  -> self <class 'boot_linux_console.BootLinuxConsole'>: 01-tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd
+13:53:12 DEBUG|  -> deb_url <class 'str'>: http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/raspberrypi-kernel_1.20190215-1_armhf.deb
+13:53:12 DEBUG|  -> deb_hash <class 'str'>: cd284220b32128c5084037553db3c482426f3972
+13:53:12 DEBUG|  -> deb_path <class 'str'>: /home/cleber/avocado/data/cache/by_location/c813ab2b9e4f63b2aa876075ad70d638a31a25b7/raspberrypi-kernel_1.20190215-1_armhf.deb
+13:53:12 DEBUG|  -> kernel_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img
+13:53:12 DEBUG|  -> dtb_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb
+13:53:12 DEBUG|  -> initrd_url <class 'str'>: https://github.com/groeck/linux-build-test/raw/2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/arm/rootfs-armv7a.cpio.gz
+13:53:12 DEBUG|  -> initrd_hash <class 'str'>: 604b2e45cdf35045846b8bbfbf2129b1891bdc9c
+13:53:12 DEBUG|  -> initrd_path_gz <class 'str'>: /home/cleber/avocado/data/cache/by_location/d100d022b257e2c8f0c0c97434576ed642f9afe5/rootfs-armv7a.cpio.gz
+13:53:12 DEBUG|  -> initrd_path <class 'str'>: /home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio
+13:53:12 DEBUG|  -> kernel_command_line <class 'str'>: printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0
+13:53:12 DEBUG| DATA (filename=output.expected) => NOT FOUND (data sources: variant, test, file)
+13:53:12 DEBUG| DATA (filename=stdout.expected) => NOT FOUND (data sources: variant, test, file)
+13:53:12 DEBUG| DATA (filename=stderr.expected) => NOT FOUND (data sources: variant, test, file)
+13:53:12 ERROR| Traceback (most recent call last):
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 514, in _do_shutdown
+    self._soft_shutdown(timeout, has_quit)
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 497, in _soft_shutdown
+    self._subp.wait(timeout=timeout)
+
+13:53:12 ERROR|   File "/usr/lib64/python3.9/subprocess.py", line 1189, in wait
+    return self._wait(timeout=timeout)
+
+13:53:12 ERROR|   File "/usr/lib64/python3.9/subprocess.py", line 1909, in _wait
+    raise TimeoutExpired(self.args, timeout)
+
+13:53:12 ERROR| subprocess.TimeoutExpired: Command '('./qemu-system-arm', '-display', 'none', '-vga', 'none', '-chardev', 'socket,id=mon,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-monitor.sock', '-mon', 'chardev=mon,mode=control', '-machine', 'raspi2b', '-chardev', 'socket,id=console,path=/var/tmp/avo_qemu_sock_hd3upfg6/qemu-2435532-console.sock,server=on,wait=off', '-serial', 'chardev:console', '-kernel', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/kernel7.img', '-dtb', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/boot/bcm2709-rpi-2-b.dtb', '-initrd', '/home/cleber/avocado/job-results/job-2021-09-24T13.48-0890f76/test-results/tmp_dirdikw83mj/01-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_raspi2_initrd/rootfs.cpio', '-append', 'printk.time=0 earlycon=pl011,0x3f201000 console=ttyAMA0 panic=-1 noreboot dwc_otg.fiq_fsm_enable=0', '-no-reboot')' timed out after 300 seconds
+
+13:53:12 ERROR| 
+The above exception was the direct cause of the following exception:
+
+
+13:53:12 ERROR| Traceback (most recent call last):
+
+13:53:12 ERROR|   File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py", line 882, in _run_avocado
+    raise test_exception
+
+13:53:12 ERROR|   File "/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.9/site-packages/avocado/core/test.py", line 789, in _run_avocado
+    testMethod()
+
+13:53:12 ERROR|   File "/var/lib/users/cleber/build/qemu/tests/acceptance/boot_linux_console.py", line 502, in test_arm_raspi2_initrd
+    self.vm.wait(300)
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 561, in wait
+    self.shutdown(has_quit=True, timeout=timeout)
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 544, in shutdown
+    self._do_shutdown(timeout, has_quit)
+
+13:53:12 ERROR|   File "/home/cleber/src/qemu/python/qemu/machine/machine.py", line 517, in _do_shutdown
+    raise AbnormalShutdown("Could not perform graceful shutdown") \
+
+13:53:12 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown
+
+13:53:12 ERROR| ERROR 01-tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_raspi2_initrd -> AbnormalShutdown: Could not perform graceful shutdown
+13:53:12 INFO | 
+```
diff --git a/results/classifier/gemma3:12b/boot/640 b/results/classifier/gemma3:12b/boot/640
new file mode 100644
index 000000000..2229a8c20
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/640
@@ -0,0 +1,7 @@
+
+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/gemma3:12b/boot/651 b/results/classifier/gemma3:12b/boot/651
new file mode 100644
index 000000000..89c06eb6f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/651
@@ -0,0 +1,2 @@
+
+powerpc: Starting machine ref405ep fails with "Could not load PowerPC BIOS 'ppc405_rom.bin'"
diff --git a/results/classifier/gemma3:12b/boot/657 b/results/classifier/gemma3:12b/boot/657
new file mode 100644
index 000000000..e6312daf6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/657
@@ -0,0 +1,2 @@
+
+qemu no valid state has been set by load or init-program Mac OS X Tiger
diff --git a/results/classifier/gemma3:12b/boot/670 b/results/classifier/gemma3:12b/boot/670
new file mode 100644
index 000000000..f875dcbce
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/670
@@ -0,0 +1,11 @@
+
+qemu x86_64 for microsoft windows hangs when booting a Debian Live 11.1 iso file
+Description of problem:
+qemu displays the boot screen from the live linux iso and starts the boot, but no more display is performed even when waiting for approximately 30 minutes
+Steps to reproduce:
+1. Get hold of a Live Linux iso from Debian 11.1
+2. Set up the Microsoft Windows version of qemu from https://qemu.weilnetz.de/
+3. Attempt to boot the Live Linux iso
+Additional information:
+I also tested older versions of QEMU from the Weilnetz web site. 6.0.0 and 5.2.0 are bad; 5.1.0 and older are good. I then tested the same command line ( no acceleration ) under Linux Tumbleweed 20211014 with qemu 6.1.0 and the iso booted successfully. I have not tried with isos from distributions other than Debian 11.1 . So there is a bug with the Microsoft Windows-specific code in qemu.
+If you need the specific Live Linux that I was using, let me know and I will get it to you somehow. It is several GB in size so I cannot upload it anywhere conveniently.
diff --git a/results/classifier/gemma3:12b/boot/673 b/results/classifier/gemma3:12b/boot/673
new file mode 100644
index 000000000..170ff9339
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/673
@@ -0,0 +1,11 @@
+
+I can no longer boot with -kernel and -initrd
+Description of problem:
+The kernel refuses to mount the initramfs and proceeds to kernel panic. i didnt have this problem until qemu updated
+Steps to reproduce:
+I have put it all in the git repo of my project
+1. git clone https://github.com/oknowaen/ltl-initramfs.git
+2. cd ltl-initramfs
+3. make (will start automatically)!
+Additional information:
+[Screenshot_20211016_182355](/uploads/c04094f5bcccadc3f8473f2ea6fc864d/Screenshot_20211016_182355.png)
diff --git a/results/classifier/gemma3:12b/boot/714629 b/results/classifier/gemma3:12b/boot/714629
new file mode 100644
index 000000000..39f6426d6
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/714629
@@ -0,0 +1,4 @@
+
+BIOS doesn't load when read() returns less than the full ROM length
+
+When qemu is running over a 9p filesystem (e.g. when running underneath -virtfs of another qemu), and probably some other network filesystems, it fails to read its BIOS image.  This is because it uses a single low-level read() call on the bios.bin, asking for the full file.  However read() may return less than the full length, and it's the caller's responsibility to call it repeatedly if necessary.  When read does come up short, qemu doesn't repeat the call, and reports an error instead.  The attached patch fixes the one problem I saw, but I haven't tried to cover the general case (e.g. extension ROMs).
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/723460 b/results/classifier/gemma3:12b/boot/723460
new file mode 100644
index 000000000..63c30c48d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/723460
@@ -0,0 +1,23 @@
+
+qemu on linux doesn't boot for winxp install via usb
+
+hi guys,
+I try to install windows xp via qemu. I can only boot from usb and somehow it is my problem.
+I run a Winxp/xubuntu10.04 Dualboot-system with some virtual drives in windows ( till letter f:? ).
+at qemu I created an image from 30Gigabytes and entered this command from the imagefile's directory :
+
+"sudo qemu-system-x86_64 -localtime -usbdevice -hda /dev/sdb -m 384 -boot d winxp.img"
+
+the answer is :
+
+"qemu-system-x86_64: -boot d: drive with bus=0, unit=0 (index=0) exists"
+
+I had to set the usb-stick in the fstab file with this command :
+
+"UUID=X	/media/usb	vfat	rw,users,noauto,umask=000	0	0"
+
+anybody experienced the same problem?
+
+I would appreciate any kind of help
+
+greetz
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/744856 b/results/classifier/gemma3:12b/boot/744856
new file mode 100644
index 000000000..510913aa4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/744856
@@ -0,0 +1,11 @@
+
+can't boot when using more than 6 disks since qemu-kvm-0.13
+
+It's not possible to pass more than 6 disks to a guest since qemu-kvm-0.13 (also tested with 0.14).
+If I pass more than 6 disks (as shown below) the machine complains that their is no bootable disk,
+
+The problem occurs with virtio and without virtio.
+
+eg.
+
+/usr/bin/qemu-system-x86_64  --enable-kvm -boot c   -drive file=/dev/vgr5/fs-01,if=virtio -drive file=/dev/vgr5/fs-01_srv_workspace,if=virtio -drive file=/dev/vgr5/fs-01_srv_media,if=virtio -drive file=/dev/vgr5/fs-01_srv_company,if=virtio -drive file=/dev/vgr5/fs-01_srv_tmp,if=virtio -drive file=/dev/vgr5/fs-01_srv_download,if=virtio -drive file=/dev/vgr5/fs-01_srv_share,if=virtio -drive file=/dev/vgr5/fs-01_srv_backup,if=virtio -drive file=/dev/vgr5/fs-01_srv_private,if=virtio -drive file=/dev/vgr5/fs-01_srv_build,if=virtio -drive file=/dev/vgr5/fs-01_srv_dev,if=virtio -drive file=/dev/vgr5/fs-01_srv_backup2,if=virtio -drive file=/dev/vgr5/fs-01_srv_ftp,if=virtio  -cpu qemu64 -smp 2  -m 4G -append root=/dev/vda -usbdevice tablet -net nic,macaddr=90:e6:ba:9d:00:0,model=e1000 -net tap,ifname=tap0,script=/usr/sbin/qemu-ifup,downscript=/usr/sbin/qemu-ifdown  -monitor unix:/var/run/kvm/fs-01/monitor,server,nowait -pidfile /var/run/kvm/fs-01/pid  -k de -kernel /srv/kvm/kernel/linux-2.6.38-gentoo -append root=/dev/vda -vnc :0 -name fs-01,process=fs-01 -vga std
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/745 b/results/classifier/gemma3:12b/boot/745
new file mode 100644
index 000000000..b606c77cb
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/745
@@ -0,0 +1,37 @@
+
+NVRAM is not persistent across coldboots without attached r/w FAT32 hard drive
+Description of problem:
+NVRAM variables are not persistent across coldboots without an attached readable / writable FAT32 hard drive.
+Steps to reproduce:
+Without hard drive:
+1. Start VM as above ("without hard drive attached"), and enter EFI shell.
+2. Dump the contents of a NVRAM variable, e.g. Lang. Note the contents.
+3. Edit the contents of that variable.
+4. Shutdown and restart the VM (cold reboot), and enter the EFI shell.
+5. Dump the contents of the same NVRAM variable. The contents have reverted to what they were in Step 2.
+
+With hard drive:
+1. Start VM as above ("with hard drive attached"), and enter EFI shell.
+2. Navigate to the hard drive filesystem, e.g. FS0.
+3. List the files in the filesystem. If NvVars exists, note the modification time.
+4. Edit the contents of a NVRAM variable, e.g. Lang.
+5. List the files of the filesystem. The NvVars file either now exists, or has notably been modified since Step 3.
+Additional information:
+OVMF blobs used: Those found in the Debian Sid package "ovmf_2021.11_rc1-1_all.deb" (https://packages.debian.org/sid/ovmf)
+
+Note that, without a hard drive attached, edited NVRAM variables persist across warm reboots, e.g. via the EFI shell command `reset`.
+
+I have not tested filesystem formats other than FAT32 with the attached hard drive, though I assume that would be futile due to the UEFI specification stating that EFI only supports FAT-based filesystems by default.
+
+Without HDD attached, before cold reboot:
+![no_hdd_pre-coldboot](/uploads/cb1da3e72a852ff1e7fd1b47afc9ba6e/no_hdd_pre-coldboot.png)
+
+Without HDD attached, after cold reboot:
+![no_hdd_post-coldboot](/uploads/d9622d4571ad8c046f51a00b26e8354e/no_hdd_post-coldboot.png)
+
+With HDD attached (note modification date / time of NvVars):
+![hdd_attached](/uploads/30135dd688f8c7e7ec2feccd69007258/hdd_attached.png)
+
+This issue leads to modern macOS's installation process failing, as it relies on being able to modify NVRAM variables to know how far along in the installation process it is. Without these variables, the installation process will loop indefinitely, as it can't know when to move on to the next part of the overall process.
+
+Let me know if more information is needed, or if this is an issue better suited for the OVMF bug tracker (which I do not know the location of).
diff --git a/results/classifier/gemma3:12b/boot/756 b/results/classifier/gemma3:12b/boot/756
new file mode 100644
index 000000000..ed130ccbd
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/756
@@ -0,0 +1,2 @@
+
+qemu-system-m68k -M q800 -bios /dev/null segfaults
diff --git a/results/classifier/gemma3:12b/boot/760956 b/results/classifier/gemma3:12b/boot/760956
new file mode 100644
index 000000000..e205faf0f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/760956
@@ -0,0 +1,21 @@
+
+Open Solaris 2009 Doesn't Boot
+
+The latest git version of qemu (commit 420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot the OpenSolaris image from http://dlc.sun.com/osol/opensolaris/2009/06/osol-0906-ai-sparc.iso.
+
+qemu-img create opensolaris 3G
+qemu-system-sparc -hda opensolaris -cdrom osol-0906-ai-sparc.iso -boot d -redir tcp:2232::22 -k en-us -m 192
+
+gives:
+
+...
+Trying cdrom:d
+File not found
+Trying cdrom...
+Not a bootable ELF image
+Not a bootable a.out image
+No valid state has been set by load or init_program
+
+Host: Linux/x86_64
+gcc4.5
+./configure --enable-linux-aio --enable-io-thread --enable-kvm
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/766 b/results/classifier/gemma3:12b/boot/766
new file mode 100644
index 000000000..4d295681a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/766
@@ -0,0 +1,28 @@
+
+qemu-system-x86_64: Reboot loop after Machine->Reset
+Description of problem:
+When using tcg, the virtual machine goes into a reboot loop after the VM
+is rebooted through UI->Machine->Reboot menu, or through outb(0xcf9, 0xf).
+There might be other reboot mechanisms that result in the same loop.
+
+The loop doesn't occur when using kvm:
+qemu-system-x86_64 -M q35 -enable-kvm
+Steps to reproduce:
+1. Run the command. (The one without -enable-kvm.)
+2. From the UI, click on Machine->Reset.
+3. See that the VM locks up, instead of resetting.
+Additional information:
+The reboot loop occurs because a variable defined by Seabios cannot be updated, possibly because the memory is read-only.
+
+The variable in question is [HaveRunPost](https://github.com/coreboot/seabios/blob/2dd4b9b3f84019668719344b40dba79d681be41c/src/fw/shadow.c#L194). If HaveRunPost is non-zero, the BIOS follows the resume path. When the reset is clicked, the BIOS does indeed gain control and follow the resume path because HaveRunPost is 2. The control ends up at qemu_reboot, which should reset HaveRunPost to 0 and trigger another reset, so that this second time around, the BIOS sees HaveRunPost as 0, and follows the initialization path instead.
+
+But, even though the instruction to update HaveRunPost seems to run, the value remains non-zero (2 to be exact).
+
+```
+        // HaveRunPost has value 2 here.
+        barrier();
+        HaveRunPost = 0;
+        barrier();
+        // If a dprintf(1, "%x\n", HaveRunPost); is placed here, the value printed is 2 and not 0!
+        // With kvm-enabled, this dprintf prints 0.
+```
diff --git a/results/classifier/gemma3:12b/boot/788697 b/results/classifier/gemma3:12b/boot/788697
new file mode 100644
index 000000000..5149a488d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/788697
@@ -0,0 +1,4 @@
+
+[PowerPC] [patch] mtmsr does not preserve high bits of MSR
+
+The mtmsr instruction on 64-bit PPC does not preserve the high-order 32-bits of the MSR the way it is supposed to, instead setting them to 0, which takes 64-bit code out of 64-bit mode. There is some code that does the right thing, but it brokenly only preserves these bits when the thread is not in 64-bit mode (i.e. when it doesn't matter). The attached patch unconditionally enables this code when TARGET_PPC64 is set, per the ISA spec, which fixes early boot failures trying to start FreeBSD/powerpc64 under qemu.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/797 b/results/classifier/gemma3:12b/boot/797
new file mode 100644
index 000000000..9f104e615
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/797
@@ -0,0 +1,10 @@
+
+ARM64 hvf fails to boot Windows 11 on 6.2.0
+Description of problem:
+On QEMU v6.1.0 with patches from @agraf manually applied, Windows 11 boots fine from the VHDX. Now that the patches have been mainlined, I would expect it to work the same but it gets stuck at EFI (no Windows "spinner").
+Steps to reproduce:
+1. `brew install qemu`
+2. Download Windows 11 VHDX from https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewARM64
+3. Run command from above.
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/boot/811683 b/results/classifier/gemma3:12b/boot/811683
new file mode 100644
index 000000000..a8ffc4b0d
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/811683
@@ -0,0 +1,25 @@
+
+7400,7410,7450 cpus vector have wrong exception prefix at reset
+
+I have a proprietary ROM implementing system calls that are executed via the 'SC' instruction. 
+
+I use qemu-0.14.1, 
+
+qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel
+
+That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x80000201). I found that the emulator jumps to 0x00000c00 instead of 0xfff00c00.
+Probably this is due to a wrong setting in target-ppc/translate_init.c:
+
+init_excp_604() correctly sets env->hreset_vector=0xfff00000UL;
+
+but
+
+init_excp_7400() says env->hreset_vector=0x00000000UL;
+
+which seems wrong. (the 7400 manual says a hard-reset jumps initializes the
+prefix to 0xfff00000.)
+
+Likewise, init_excp_7450() (and probably other, related CPUs) are wrong.
+
+Indeed, when I change the value in init_excp_7400() to 0xfff00000UL then
+everything works as expected for me.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/818647 b/results/classifier/gemma3:12b/boot/818647
new file mode 100644
index 000000000..7e787b5f3
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/818647
@@ -0,0 +1,79 @@
+
+Getting segmentation fault when trying to boot FreeBSD
+
+wkoszek@wkoszek:~/bin/qemu/qemu$ git log | head -1
+commit c886edfb851c0c590d4e77f058f2ec8ed95ad1b5
+
+wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ qemu-system-sparc64 --version
+QEMU emulator version 0.15.50, Copyright (c) 2003-2008 Fabrice Bellard
+
+wkoszek@wkoszek:~/o/freebsd/sys/boot/i386$ uname -a
+Linux wkoszek 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:05:41 UTC 2011 i686 i686 i386 GNU/Linux
+
+Qemu built with default settings (./configure --prefix=<path> && make && make install)
+
+I run FreeBSD ISO image:
+/home/wkoszek/bin/qemu-dynamic/bin/qemu-system-sparc64 -m 1024 -cdrom ~/Pulpit/iso/FreeBSD-7.4-RELEASE-sparc64-bootonly.iso -hda ~/Pulpit/iso/freebsd_sparc64.qcow2 -nographic -boot d
+
+Configuration device id QEMU version 1 machine id 0
+kernel cmdline 
+CPUs: 1 x SUNW,UltraSPARC-IIi
+UUID: 00000000-0000-0000-0000-000000000000
+Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17
+  Type 'help' for detailed information
+Trying cdrom:f...
+Not a bootable ELF image
+Loading a.out image...
+Loaded 7680 bytes
+entry point is 0x4000
+
+Jumping to entry point 0000000000004000 for type 0000000000000005...
+switching to new context: entry point 0x4000 stack 0x00000000ffe86b49
+ 
+>> FreeBSD/sparc64 boot block
+   Boot path:   cdrom:f
+   Boot loader: /boot/loader
+Consoles: Open Firmware console  
+
+Booting with sun4u support.
+Boot path set to cdrom:a
+
+FreeBSD/sparc64 bootstrap loader, Revision 1.0
+(<email address hidden>, Fri Feb 18 05:38:31 UTC 2011)
+bootpath="cdrom:a"
+Loading /boot/defaults/loader.conf 
+/boot/kernel/kernel data=0x8d1f48+0x82f88 syms=[0x8+0x88ec0+0x8+0x76966]
+|
+Unimplemented service milliseconds ([0] -- [1])
+Hit [Enter] to boot immediately, or any other key for command prompt.
+Unimplemented service milliseconds ([0] -- [1])
+Unimplemented service milliseconds ([0] -- [1])
+Unimplemented service milliseconds ([0] -- [1])
+Unimplemented service milliseconds ([0] -- [1])
+Unimplemented service milliseconds ([0] -- [1])
+Unimplemented service milliseconds ([0] -- [1])
+
+I press CTRL + C and I get out of the looped warning about "unimplemented service". Then I see:
+
+Type '?' for a list of commands, 'help' for more detailed help.
+OK boot
+jumping to kernel entry at 0xc0078000.
+BOOTUnhandled Exception 0x0000000000000034
+PC = 0x00000000c0637454 NPC = 0x00000000c0637458
+
+I wanted to start FreeBSD debugging here - I pressed 'CTRL+A c', I was dropped to the monitor.
+
+FRom the monitor I typed:
+
+Stopping execution
+QEMU 0.15.50 monitor - type 'help' for more information
+(qemu) x 0xc0078000
+00000000c0078000: Cannot access memory
+(qemu) x 0x00000000c0637454 
+00000000c0637454: Cannot access memory
+(qemu) x 0x00000000c0637458
+00000000c0637458: Cannot access memory
+(qemu) xp 0xc0078000
+Segmentation fault
+
+IMO it shouldn't have crashed.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/820 b/results/classifier/gemma3:12b/boot/820
new file mode 100644
index 000000000..ef02daa1c
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/820
@@ -0,0 +1,14 @@
+
+Hang During Initramfs
+Description of problem:
+[Hang During Initramfs](https://wiki.archlinux.org/title/QEMU#Hang_during_VM_initramfs)
+Is this still not fixed? I hang at startup. Previously I tried WIN11 and it booted fine.
+Steps to reproduce:
+1. Download Windows10 ISO
+2. qemu-img create -f raw Windows10 15G
+3. qemu-system-x86_64 -cdrom Win10.iso -boot order=d -drive file=Windows10,format=raw -m 4G
+Additional information:
+![qemu](/uploads/e122ebddb51e29de9bd16bc1815bb98e/qemu.mp4)
+
+
+`-enable-kvm` works but i removed it to slow down a bit to see what is going on.
diff --git a/results/classifier/gemma3:12b/boot/830833 b/results/classifier/gemma3:12b/boot/830833
new file mode 100644
index 000000000..84180d2f4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/830833
@@ -0,0 +1,14 @@
+
+sparc emulators fail to boot
+
+The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) doesn't boot sparc.  It fails to boot both Linux and NetBSD kernels with this error:
+
+Configuration device id QEMU version 1 machine id 32
+CPUs: 1 x FMI,MB86904
+UUID: 00000000-0000-0000-0000-000000000000
+Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16
+  Type 'help' for detailed information
+Trying disk...
+Unhandled Exception 0x0000002a
+PC = 0xffd10bdc NPC = 0xffd10be0
+Stopping execution
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/833658 b/results/classifier/gemma3:12b/boot/833658
new file mode 100644
index 000000000..2c53de0b2
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/833658
@@ -0,0 +1,7 @@
+
+Qemu ppc does not boot Debian 3.1r8
+
+I tried booting the official image debian-31r8-powerpc-binary-1.iso with the following commandline:
+qemu-system-ppc -boot d -cdrom ../debian-31r8-powerpc-binary-1.iso -hda hd.img. The booting process stops with CPU at 100%. I can choose to boot "install-2.4" or "install" which both hangs with the last output being "Loading ramdisk". I have also tried using the git-tree which crashes qemu with the message "qemu/memory.c:1183: memory_region_add_subregion_common: Assertion `!subregion->parent' failed." before even showing anything.
+
+Additionally, qemu 0.14.1 shows the same behaviour but qemu 0.13 and 0.12.5 can boot beyond the "Loading ramdisk" message but stops immediatly afterwards with a messed up console window (letters are pushed into another, which makes them barely readable) when using "install". Also "install-2.4" boots with 0.13 and 0.12.5 beyond the "Loading ramdisk" message but stops with the last message being now "returning 0x01400000 from prom_init".
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/842290 b/results/classifier/gemma3:12b/boot/842290
new file mode 100644
index 000000000..50fcdbb59
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/842290
@@ -0,0 +1,12 @@
+
+MIPS Malta mini-bootloader print function has bad jump instruction
+
+One of the hardcoded bootloader library instructions in the MIPS Malta mini-bootloader's print function is:
+
+stl_raw(p++, 0x08000205);                                     /* j 814 */
+
+Since this function is loaded at 0xbfc00808, this jump jumps to the middle of nowhere. The properly-encoded instruction is:
+
+stl_raw(p++, 0x0bf00205);                                     /* j 814 */
+
+With this patch, the print function behaves as expected.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/855 b/results/classifier/gemma3:12b/boot/855
new file mode 100644
index 000000000..c2dbdd97f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/855
@@ -0,0 +1,18 @@
+
+Prebuilt seabios vgabios-stdvga binary causes onboot kernel panics for freebsd 10.0
+Description of problem:
+FreeBSD 10.0 panics on boot since commit: `0221d73ce6a8e075adaa0a35a6ef853d2652b855`, see my attached screenshot of the panic. 
+I digged a bit into what specifically causes the issue, it seems to be caused by the precompiled `vgabios-stdvga.bin`. 
+I don't see this issue come up when I compile the binary myself via the `roms/` folder with different versions of gcc via gcc docker containers. 
+But once I compile the `vgabios-stdvga` from the `roms/` folder with a more modern Ubuntu version (21.10) using gcc 11.2, I also get panics on my `vgabios-stdvga`. 
+At first I thought it was caused by a different gcc version, but since the buster gcc docker container images create correctly functioning `vgabios-stdvga.bin` binaries, I think this is caused by a newer version of the linker coming from the `binutils` package.
+
+My local Ubuntu version has version 2.37 of the binutils package, the `gcc:11.2` container which compiles a correct `vgabios-stdvga.bin` has version `2.35.2` of the binutils package.
+
+![Screenshot_from_2022-02-03_17-35-59](/uploads/5bafeca625ebe8b38acd5a0d6c358392/Screenshot_from_2022-02-03_17-35-59.png)
+Steps to reproduce:
+1. Compile any version after the mentioned commit using the precompiled seabios binaries
+2. Try to boot freebsd 10.0-RELEASE
+3. Kernel panic because of a page vault during the vesa module load.
+Additional information:
+https://mfsbsd.vx.sk/files/iso/10/amd64/mfsbsd-10.0-RELEASE-amd64.iso
diff --git a/results/classifier/gemma3:12b/boot/859 b/results/classifier/gemma3:12b/boot/859
new file mode 100644
index 000000000..658fc8c99
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/859
@@ -0,0 +1,2 @@
+
+PowerPC's Virtual Open Firmware uses an unsupported instruction in older CPUs
diff --git a/results/classifier/gemma3:12b/boot/87 b/results/classifier/gemma3:12b/boot/87
new file mode 100644
index 000000000..68b74a28b
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/87
@@ -0,0 +1,2 @@
+
+doesn't clear screen on boot
diff --git a/results/classifier/gemma3:12b/boot/893 b/results/classifier/gemma3:12b/boot/893
new file mode 100644
index 000000000..15ceb621a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/893
@@ -0,0 +1,2 @@
+
+Cannot boot and set rhel7 or 8 s390x on Redhat 8(Host OS) using qemu-system-s390x
diff --git a/results/classifier/gemma3:12b/boot/893208 b/results/classifier/gemma3:12b/boot/893208
new file mode 100644
index 000000000..84c0421ad
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/893208
@@ -0,0 +1,4 @@
+
+qemu on ARM hosts can't boot i386 image
+
+If you apply some workarounds for bug 870990, bug 883133 and bug 883136 QEMU still cannot boot the i386 debian_squeeze_i386_standard.qcow2 image from http://people.debian.org/~aurel32/qemu/i386/ -- grub starts to boot but something causes the system to reset just before display of the blue-background grub menu, so we go round in a loop forever. This image boots OK on i386 hosted qemu so this indicates some kind of ARM-host specific bug.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/902 b/results/classifier/gemma3:12b/boot/902
new file mode 100644
index 000000000..8cd1226e7
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/902
@@ -0,0 +1,2 @@
+
+BootLinuxS390X test failing due to a TCG bug
diff --git a/results/classifier/gemma3:12b/boot/912983 b/results/classifier/gemma3:12b/boot/912983
new file mode 100644
index 000000000..bebc3d628
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/912983
@@ -0,0 +1,45 @@
+
+Unable to install OS/2 Warp v3 past disk 2
+
+To whom it may concern,
+
+As you may (or may not) be aware, QEMU is currently unable to readily install OS/2 Warp v3 (OS2W3) when asked for Installation Diskette 2 (http://www.claunia.com/qemu/objectManager.php?sClass=version&iId=132&iTestingId=138).
+
+QEMU 0.8.2 is the last known (to me) release to successfully install OS2W3. QEMU version 1.0 and the latest development version (as of 2012-01-05) have been verified not to work.
+
+A 'git bisect' reveals the issue was introduced during a migration to new removable media handling prior to the QEMU 0.9.0 release:
+
+	There are only 'skip'ped commits left to test.
+	The first bad commit could be any of:
+	66c6ef7678939f2119eb649074babf5d5b2666f6
+	ea185bbda732dae6b6a5a44699f90c83e21f1494
+	19cb37389f4641d48803f0c5d72708749cbcf318
+	We cannot bisect more!
+
+For testing, the 'qcow' hard drive format was chosen due to QEMU 0.8.2 not having 'qcow2':
+
+	$ qemu -M isapc -m 8 -localtime -soundhw sb16 -hda os2.qcow -fda install.img -boot a
+
+Of note, the ISA-only PC (isapc) was needed for QEMU 0.8.2 to 0.9.0. Otherwise QEMU hangs on start-up. Later versions of QEMU, segmentation fault when attempting to use '-M isapc' though boot correctly when using the default PC machine.
+
+
+The currently preferred method to install OS2W3 is to use another application (such as VirtualBox or VMWare), using a QEMU compatible disk image format. Once installed, QEMU can then run OS2W3; which it does phenomenally well.
+
+However, I've identified a way to install OS2W3 exclusively with QEMU, which may also shed additional light on the issue.
+
+1. Using a relatively new QEMU (I'm on 0.11.1), install OS2W3 as you normally would on to a 'qcow2' hard drive.
+2. When Installation Diskette 2 is reached, save a VM snapshot.
+3. Quit QEMU and re-run, loading the VM state *with* the Installation Diskette 2 image in the floppy drive.
+	$ qemu -m 8 -localtime -soundhw sb16 -hda os2.qcow2 -fda disk2.img -loadvm install 
+The installation process will then continue as normal.
+
+This same method can be used once OS2W3 continues installing from it's GUI. Installation Diskette 7 experiences the same issue of not being recognised when inserted.
+
+Of note, as an unrelated issue, I was unable to save VM snapshots in QEMU 1.0 or later.
+
+
+Thank you for a fantastic emulator.
+
+
+cheers,
+multitude
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/930 b/results/classifier/gemma3:12b/boot/930
new file mode 100644
index 000000000..26267fd7a
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/930
@@ -0,0 +1,2 @@
+
+Impossible to make windows 98 work on Qemu ver. 5.2
diff --git a/results/classifier/gemma3:12b/boot/944628 b/results/classifier/gemma3:12b/boot/944628
new file mode 100644
index 000000000..399ddf1c0
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/944628
@@ -0,0 +1,10 @@
+
+Documentation for mtdblock, option-rom, and pflash is non-existent
+
+The options -mtdblock, -option-rom, and -pflash are severely under-documented.  For example:
+
+-mtdblock  -- It isn't at all clear what this does from --help or the documentation, and it's especially not clear that it's only implemented for ARM right now
+
+-option-rom is only implemented for a handful of architectures, including palm, pc, pci, and one or two others
+
+-pflash looks to be implemented for most if not all architectures, but there's nothing informing the user that it replaces the bios if -bios isn't used in tandem with -pflash, and it isn't clear whether the user could add multiple pflash roms
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/965327 b/results/classifier/gemma3:12b/boot/965327
new file mode 100644
index 000000000..7e8504416
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/965327
@@ -0,0 +1,737 @@
+
+virtio-pci: can't reserve io 0x0000-0x001f
+
+Before 2012-03-05 I was able to successfully enable a virtio-pci block device from a sPAPR pseries ppc64 Linux guest. With the current git master branch after this date I get the following error:
+
+virtio-pci 0000:00:00.0: device not available (can't reserve [io  0x0000-0x001f])
+virtio-pci: probe of 0000:00:00.0 failed with error -22
+virtio-pci 0000:00:01.0: device not available (can't reserve [io  0x0000-0x003f])
+virtio-pci: probe of 0000:00:01.0 failed with error -22
+
+
+Full details:
+
+-----------------
+command line:
+-----------------
+     ./testing/qemu/ppc64-softmmu/qemu-system-ppc64 \
+			-L ./testing/qemu/pc-bios \
+			-M pseries \
+			-m 1024 \
+			-rtc base=localtime \
+			-parallel none \
+			-netdev type=user,id=mynet0,hostfwd=tcp:127.0.0.1:9011-10.0.2.11:22 \
+			-device virtio-net-pci,netdev=mynet0 \
+			-drive file=images/suse-ppc.img,if=virtio,index=0,media=disk,cache=unsafe \
+			-kernel images/iso/suseboot/vmlinux \
+			-append "root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0" \
+			-initrd images/iso/suseboot/initrd.img \
+			-gdb tcp::1234
+
+
+------------------------------------------------------
+BEFORE virtio-pci "bug/user error?" introduced:
+------------------------------------------------------
+sPAPR memory map:
+RTAS                 : 0x3fff0000..3fff0013
+FDT                  : 0x3ffe0000..3ffeffff
+Kernel               : 0x00400000..01abad7b
+Ramdisk              : 0x01ad0000..02053df7
+Firmware load        : 0x00000000..000d6ec0
+Firmware runtime     : 0x3d7e0000..3ffe0000
+sPAPR reset
+
+SLOF **********************************************************************
+QEMU Starting
+Build Date = Mar  3 2012 21:46:40
+ FW Version = git-440e662879c4fc3c
+ Press "s" to enter Open Firmware.
+
+Populating /vdevice methods
+Populating /vdevice/v-scsi@2000
+VSCSI: Initializing
+VSCSI: Looking for disks
+  SCSI ID 2 CD-ROM   : "QEMU     QEMU CD-ROM      1.0."
+Populating /vdevice/vty@30000000
+Populating /pci@0,0
+ Adapters on 0000000000000000
+                     00 0000 (D) : 1af4 1000    virtio [ net ]
+                     00 0800 (D) : 1af4 1001    virtio [ block ]
+No NVRAM common partition, re-initializing...
+Using default console: /vdevice/vty@30000000
+Detected RAM kernel at 400000 (16bad7c bytes)
+
+  Welcome to Open Firmware
+
+  Copyright (c) 2004, 2011 IBM Corporation All rights reserved.
+  This program and the accompanying materials are made available
+  under the terms of the BSD License available at
+  http://www.opensource.org/licenses/bsd-license.php
+
+Booting from memory...
+OF stdout device is: /vdevice/vty@30000000
+Preparing to boot Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+Detected machine type: 0000000000000101
+Max number of cores passed to firmware: 1024 (NR_CPUS = 1024)
+Calling ibm,client-architecture-support... not implemented
+couldn't open /packages/elf-loader
+command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0
+memory layout at init:
+  memory_limit : 0000000000000000 (16 MB aligned)
+  alloc_bottom : 0000000001ad0000
+  alloc_top    : 0000000030000000
+  alloc_top_hi : 0000000040000000
+  rmo_top      : 0000000030000000
+  ram_top      : 0000000040000000
+instantiating rtas at 0x000000002fff0000... done
+Querying for OPAL presence... not there.
+boot cpu hw idx 0
+copying OF device tree...
+Building dt strings...
+Building dt structure...
+Device tree strings 0x00000000020e0000 -> 0x00000000020e0635
+Device tree struct  0x00000000020f0000 -> 0x0000000002100000
+Calling quiesce...
+returning from prom_init
+Using pSeries machine description
+Using 1TB segments
+Found initrd at 0xc000000001ad0000:0xc000000002053df8
+bootconsole [udbg0] enabled
+CPU maps initialized for 1 thread per core
+Starting Linux PPC64 #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+-----------------------------------------------------
+ppc64_pft_size                = 0x18
+physicalMemorySize            = 0x40000000
+htab_hash_mask                = 0x1ffff
+-----------------------------------------------------
+Initializing cgroup subsys cpuset
+Initializing cgroup subsys cpu
+Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+CF000012
+Setup Arch[boot]0012 Setup Arch
+PCI host bridge /pci@0,0  ranges:
+  IO 0x0000010080000000..0x000001008000ffff -> 0x0000000000000000
+ MEM 0x00000100a0000000..0x00000100bfffffff -> 0x0000000080000000 
+Zone PFN ranges:
+  DMA      0x00000000 -> 0x00004000
+  Normal   empty
+Movable zone start PFN for each node
+early_node_map[1] active PFN ranges
+    0: 0x00000000 -> 0x00004000
+CF000015
+Setup Done[boot]0015 Setup Done
+PERCPU: Embedded 2 pages/cpu @c000000002200000 s83840 r0 d47232 u1048576
+Built 1 zonelists in Node order, mobility grouping on.  Total pages: 16370
+Policy zone: DMA
+Kernel command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0
+audit: disabled (until reboot)
+PID hash table entries: 4096 (order: -1, 32768 bytes)
+freeing bootmem node 0
+Memory: 1014336k/1048576k available (18112k kernel code, 34240k reserved, 2048k data, 3115k bss, 6272k init)
+Hierarchical RCU implementation.
+	CONFIG_RCU_FANOUT set to non-default value of 32
+	RCU dyntick-idle grace-period acceleration is enabled.
+NR_IRQS:512 nr_irqs:512 16
+clocksource: timebase mult[7d0000] shift[22] registered
+Console: colour dummy device 80x25
+console [tty0] enabled
+Using pSeries machine description
+Using 1TB segments
+Found initrd at 0xc000000001ad0000:0xc000000002053df8
+bootconsole [udbg0] enabled
+CPU maps initialized for 1 thread per core
+Starting Linux PPC64 #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+-----------------------------------------------------
+ppc64_pft_size                = 0x18
+physicalMemorySize            = 0x40000000
+htab_hash_mask                = 0x1ffff
+-----------------------------------------------------
+Initializing cgroup subsys cpuset
+Initializing cgroup subsys cpu
+Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+[boot]0012 Setup Arch
+PCI host bridge /pci@0,0  ranges:
+  IO 0x0000010080000000..0x000001008000ffff -> 0x0000000000000000
+ MEM 0x00000100a0000000..0x00000100bfffffff -> 0x0000000080000000 
+Zone PFN ranges:
+  DMA      0x00000000 -> 0x00004000
+  Normal   empty
+Movable zone start PFN for each node
+early_node_map[1] active PFN ranges
+    0: 0x00000000 -> 0x00004000
+[boot]0015 Setup Done
+PERCPU: Embedded 2 pages/cpu @c000000002200000 s83840 r0 d47232 u1048576
+Built 1 zonelists in Node order, mobility grouping on.  Total pages: 16370
+Policy zone: DMA
+Kernel command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0
+audit: disabled (until reboot)
+PID hash table entries: 4096 (order: -1, 32768 bytes)
+freeing bootmem node 0
+Memory: 1014336k/1048576k available (18112k kernel code, 34240k reserved, 2048k data, 3115k bss, 6272k init)
+Hierarchical RCU implementation.
+	CONFIG_RCU_FANOUT set to non-default value of 32
+	RCU dyntick-idle grace-period acceleration is enabled.
+NR_IRQS:512 nr_irqs:512 16
+clocksource: timebase mult[7d0000] shift[22] registered
+Console: colour dummy device 80x25
+console [tty0] enabled
+console [hvc0] enabled
+console [hvc0] enabled
+allocated 524288 bytes of page_cgroup
+allocated 524288 bytes of page_cgroup
+please try 'cgroup_disable=memory' option if you don't want memory cgroups
+please try 'cgroup_disable=memory' option if you don't want memory cgroups
+pid_max: default: 32768 minimum: 301
+pid_max: default: 32768 minimum: 301
+Security Framework initialized
+Security Framework initialized
+AppArmor: AppArmor disabled by boot time parameter
+AppArmor: AppArmor disabled by boot time parameter
+Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes)
+Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes)
+Inode-cache hash table entries: 65536 (order: 3, 524288 bytes)
+Inode-cache hash table entries: 65536 (order: 3, 524288 bytes)
+Mount-cache hash table entries: 4096
+Mount-cache hash table entries: 4096
+Initializing cgroup subsys cpuacct
+Initializing cgroup subsys cpuacct
+Initializing cgroup subsys memory
+Initializing cgroup subsys memory
+Initializing cgroup subsys devices
+Initializing cgroup subsys devices
+Initializing cgroup subsys freezer
+Initializing cgroup subsys freezer
+Initializing cgroup subsys net_cls
+Initializing cgroup subsys net_cls
+Initializing cgroup subsys blkio
+Initializing cgroup subsys blkio
+Initializing cgroup subsys perf_event
+Initializing cgroup subsys perf_event
+POWER7 performance monitor hardware support registered
+POWER7 performance monitor hardware support registered
+Brought up 1 CPUs
+Brought up 1 CPUs
+Enabling Asymmetric SMT scheduling
+Enabling Asymmetric SMT scheduling
+devtmpfs: initialized
+devtmpfs: initialized
+print_constraints: dummy: 
+print_constraints: dummy: 
+NET: Registered protocol family 16
+NET: Registered protocol family 16
+IBM eBus Device Driver
+IBM eBus Device Driver
+nvram: No room to create ibm,rtas-log partition, deleting any obsolete OS partitions...
+nvram: No room to create ibm,rtas-log partition, deleting any obsolete OS partitions...
+nvram: Failed to find or create ibm,rtas-log partition, err -28
+nvram: Failed to find or create ibm,rtas-log partition, err -28
+nvram: No room to create lnx,oops-log partition, deleting any obsolete OS partitions...
+nvram: No room to create lnx,oops-log partition, deleting any obsolete OS partitions...
+nvram: Failed to find or create lnx,oops-log partition, err -28
+nvram: Failed to find or create lnx,oops-log partition, err -28
+SUSE Linux
+#1 SMP Wed Jan 2CPU Hotplug not supported by firmware - disabling.
+CPU Hotplug not supported by firmware - disabling.
+PCI: Probing PCI hardware
+PCI: Probing PCI hardware
+pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:00.0 dn=/pci@0,0/ethernet@0
+pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:00.0 dn=/pci@0,0/ethernet@0
+pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:01.0 dn=/pci@0,0/scsi@1
+pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:01.0 dn=/pci@0,0/scsi@1
+opal: Node not found
+opal: Node not found
+bio: create slab <bio-0> at 0
+bio: create slab <bio-0> at 0
+vgaarb: loaded
+vgaarb: loaded
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver hub
+usbcore: registered new interface driver hub
+usbcore: registered new device driver usb
+usbcore: registered new device driver usb
+NetLabel: Initializing
+NetLabel: Initializing
+NetLabel:  domain hash size = 128
+NetLabel:  domain hash size = 128
+NetLabel:  protocols = UNLABELED CIPSOv4
+NetLabel:  protocols = UNLABELED CIPSOv4
+NetLabel:  unlabeled traffic allowed by default
+NetLabel:  unlabeled traffic allowed by default
+Switching to clocksource timebase
+Switching to clocksource timebase
+NET: Registered protocol family 2
+NET: Registered protocol family 2
+IP route cache hash table entries: 8192 (order: 0, 65536 bytes)
+IP route cache hash table entries: 8192 (order: 0, 65536 bytes)
+TCP established hash table entries: 32768 (order: 3, 524288 bytes)
+TCP established hash table entries: 32768 (order: 3, 524288 bytes)
+TCP bind hash table entries: 32768 (order: 3, 524288 bytes)
+TCP bind hash table entries: 32768 (order: 3, 524288 bytes)
+TCP: Hash tables configured (established 32768 bind 32768)
+TCP: Hash tables configured (established 32768 bind 32768)
+TCP reno registered
+TCP reno registered
+UDP hash table entries: 2048 (order: 0, 65536 bytes)
+UDP hash table entries: 2048 (order: 0, 65536 bytes)
+UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
+UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
+NET: Registered protocol family 1
+NET: Registered protocol family 1
+Unpacking initramfs...
+Unpacking initramfs...
+Freeing initrd memory: 5696k freed
+Freeing initrd memory: 5696k freed
+rtasd: No event-scan on system
+rtasd: No event-scan on system
+rtas_flash: no firmware flash support
+rtas_flash: no firmware flash support
+IOMMU table initialized, virtual merging enabled
+IOMMU table initialized, virtual merging enabled
+vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable
+vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable
+HugeTLB registered 16 MB page size, pre-allocated 0 pages
+HugeTLB registered 16 MB page size, pre-allocated 0 pages
+VFS: Disk quotas dquot_6.5.2
+VFS: Disk quotas dquot_6.5.2
+Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
+Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
+msgmni has been set to 1992
+msgmni has been set to 1992
+Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
+Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
+io scheduler noop registered
+io scheduler noop registered
+io scheduler deadline registered
+io scheduler deadline registered
+io scheduler cfq registered (default)
+io scheduler cfq registered (default)
+pci_hotplug: PCI Hot Plug PCI Core version: 0.5
+pci_hotplug: PCI Hot Plug PCI Core version: 0.5
+rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
+rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
+rpadlpar_io_init: partition not DLPAR capable
+rpadlpar_io_init: partition not DLPAR capable
+Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+pmac_zilog: 0.6 (Benjamin Herrenschmidt <email address hidden>)
+pmac_zilog: 0.6 (Benjamin Herrenschmidt <email address hidden>)
+Fixed MDIO Bus: probed
+Fixed MDIO Bus: probed
+arcnet loaded.
+arcnet loaded.
+ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+mousedev: PS/2 mouse device common for all mice
+mousedev: PS/2 mouse device common for all mice
+EDAC MC: Ver: 2.1.0
+EDAC MC: Ver: 2.1.0
+usbcore: registered new interface driver usbhid
+usbcore: registered new interface driver usbhid
+usbhid: USB HID core driver
+usbhid: USB HID core driver
+TCP cubic registered
+TCP cubic registered
+NET: Registered protocol family 10
+NET: Registered protocol family 10
+NET: Registered protocol family 15
+NET: Registered protocol family 15
+lib80211: common routines for IEEE802.11 drivers
+lib80211: common routines for IEEE802.11 drivers
+Registering the dns_resolver key type
+Registering the dns_resolver key type
+libceph: loaded (mon/osd proto 15/24, osdmap 5/6 5/6)
+libceph: loaded (mon/osd proto 15/24, osdmap 5/6 5/6)
+turn off boot console udbg0
+turn off boot console udbg0
+registered taskstats version 1
+/home/abuild/rpmbuild/BUILD/kernel-ppc64-3.2.0/linux-3.2/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
+Freeing unused kernel memory: 6272k freed
+doing fast boot
+device-mapper: uevent: version 1.0.3
+device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: <email address hidden>
+SCSI subsystem initialized
+alua: device handler registered
+rdac: device handler registered
+hp_sw: device handler registered
+emc: device handler registered
+Creating device nodes with udev
+udevd[78]: starting version 173
+virtio-pci 0000:00:00.0: enabling device (0100 -> 0101)
+virtio-pci 0000:00:01.0: enabling device (0100 -> 0101)
+udevd[95]: failed to execute '/etc/sysconfig/network/scripts/ifup-sysctl' '/etc/sysconfig/network/scripts/ifup-sysctl lo -o hotplug': No such file or directory
+
+ vda: [mac] vda1 vda2 vda3 vda4
+mount: devpts already mounted or /dev/pts busy
+mount: according to mtab, devpts is already mounted on /dev/pts
+Boot logging started on /dev/hvc0(/dev/console) at Mon Mar 26 10:04:22 2012
+md: linear personality registered for level -1
+  3 logical volume(s) in volume group "system" now active
+  3 logical volume(s) in volume group "system" now active
+resume device  not found (ignoring)
+Waiting for device /dev/mapper/system-root to appear:  ok
+fsck from util-linux 2.21
+[/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/mapper/system-root 
+
+[...continues normally...]
+
+
+------------------------------------------------------
+AFTER virtio-pci "bug/user error?" introduced:
+------------------------------------------------------
+sPAPR memory map:
+RTAS                 : 0x3fff0000..3fff0013
+FDT                  : 0x3ffe0000..3ffeffff
+Kernel               : 0x00400000..01abad7b
+Ramdisk              : 0x01ad0000..02053df7
+Firmware load        : 0x00000000..000d6ec0
+Firmware runtime     : 0x3d7e0000..3ffe0000
+sPAPR reset
+
+SLOF **********************************************************************
+QEMU Starting
+Build Date = Mar  3 2012 21:46:40
+ FW Version = git-440e662879c4fc3c
+ Press "s" to enter Open Firmware.
+
+Populating /vdevice methods
+Populating /vdevice/v-scsi@2000
+VSCSI: Initializing
+VSCSI: Looking for disks
+Populating /vdevice/vty@30000000
+Populating /pci@800000020000001,0
+ Adapters on 0800000020000001
+                     00 0000 (D) : 1af4 1000    virtio [ net ]
+                     00 0800 (D) : 1af4 1001    virtio [ block ]
+No NVRAM common partition, re-initializing...
+Using default console: /vdevice/vty@30000000
+Detected RAM kernel at 400000 (16bad7c bytes)
+
+  Welcome to Open Firmware
+
+  Copyright (c) 2004, 2011 IBM Corporation All rights reserved.
+  This program and the accompanying materials are made available
+  under the terms of the BSD License available at
+  http://www.opensource.org/licenses/bsd-license.php
+
+Booting from memory...
+OF stdout device is: /vdevice/vty@30000000
+Preparing to boot Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+Detected machine type: 0000000000000101
+Max number of cores passed to firmware: 1024 (NR_CPUS = 1024)
+Calling ibm,client-architecture-support... not implemented
+couldn't open /packages/elf-loader
+command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0
+memory layout at init:
+  memory_limit : 0000000000000000 (16 MB aligned)
+  alloc_bottom : 0000000001ad0000
+  alloc_top    : 0000000030000000
+  alloc_top_hi : 0000000040000000
+  rmo_top      : 0000000030000000
+  ram_top      : 0000000040000000
+instantiating rtas at 0x000000002fff0000... done
+Querying for OPAL presence... not there.
+boot cpu hw idx 0
+copying OF device tree...
+Building dt strings...
+Building dt structure...
+Device tree strings 0x00000000020e0000 -> 0x00000000020e062f
+Device tree struct  0x00000000020f0000 -> 0x0000000002100000
+Calling quiesce...
+returning from prom_init
+Using pSeries machine description
+Using 1TB segments
+Found initrd at 0xc000000001ad0000:0xc000000002053df8
+bootconsole [udbg0] enabled
+CPU maps initialized for 1 thread per core
+Starting Linux PPC64 #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+-----------------------------------------------------
+ppc64_pft_size                = 0x18
+physicalMemorySize            = 0x40000000
+htab_hash_mask                = 0x1ffff
+-----------------------------------------------------
+Initializing cgroup subsys cpuset
+Initializing cgroup subsys cpu
+Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+CF000012
+Setup Arch[boot]0012 Setup Arch
+PCI host bridge /pci@800000020000001,0  ranges:
+  IO 0x0000000000000100..0x80000000000000ff -> 0xa0fa220000000000
+Zone PFN ranges:
+  DMA      0x00000000 -> 0x00004000
+  Normal   empty
+Movable zone start PFN for each node
+early_node_map[1] active PFN ranges
+    0: 0x00000000 -> 0x00004000
+CF000015
+Setup Done[boot]0015 Setup Done
+PERCPU: Embedded 2 pages/cpu @c000000002200000 s83840 r0 d47232 u1048576
+Built 1 zonelists in Node order, mobility grouping on.  Total pages: 16370
+Policy zone: DMA
+Kernel command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0
+audit: disabled (until reboot)
+PID hash table entries: 4096 (order: -1, 32768 bytes)
+freeing bootmem node 0
+Memory: 1014336k/1048576k available (18112k kernel code, 34240k reserved, 2048k data, 3115k bss, 6272k init)
+Hierarchical RCU implementation.
+	CONFIG_RCU_FANOUT set to non-default value of 32
+	RCU dyntick-idle grace-period acceleration is enabled.
+NR_IRQS:512 nr_irqs:512 16
+clocksource: timebase mult[7d0000] shift[22] registered
+Console: colour dummy device 80x25
+console [tty0] enabled
+Using pSeries machine description
+Using 1TB segments
+Found initrd at 0xc000000001ad0000:0xc000000002053df8
+bootconsole [udbg0] enabled
+CPU maps initialized for 1 thread per core
+Starting Linux PPC64 #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+-----------------------------------------------------
+ppc64_pft_size                = 0x18
+physicalMemorySize            = 0x40000000
+htab_hash_mask                = 0x1ffff
+-----------------------------------------------------
+Initializing cgroup subsys cpuset
+Initializing cgroup subsys cpu
+Linux version 3.2.0-2-ppc64 (geeko@buildhost) (gcc version 4.6.2 20111212 [gcc-4_6-branch revision 182222] (SUSE Linux) ) #1 SMP Wed Jan 25 10:51:08 UTC 2012 (2206a5c)
+[boot]0012 Setup Arch
+PCI host bridge /pci@800000020000001,0  ranges:
+  IO 0x0000000000000100..0x80000000000000ff -> 0xa0fa220000000000
+Zone PFN ranges:
+  DMA      0x00000000 -> 0x00004000
+  Normal   empty
+Movable zone start PFN for each node
+early_node_map[1] active PFN ranges
+    0: 0x00000000 -> 0x00004000
+[boot]0015 Setup Done
+PERCPU: Embedded 2 pages/cpu @c000000002200000 s83840 r0 d47232 u1048576
+Built 1 zonelists in Node order, mobility grouping on.  Total pages: 16370
+Policy zone: DMA
+Kernel command line: root=/dev/mapper/system-root ro audit=0 selinux=0 apparmor=0 console=tty0 console=ttyPZ0
+audit: disabled (until reboot)
+PID hash table entries: 4096 (order: -1, 32768 bytes)
+freeing bootmem node 0
+Memory: 1014336k/1048576k available (18112k kernel code, 34240k reserved, 2048k data, 3115k bss, 6272k init)
+Hierarchical RCU implementation.
+	CONFIG_RCU_FANOUT set to non-default value of 32
+	RCU dyntick-idle grace-period acceleration is enabled.
+NR_IRQS:512 nr_irqs:512 16
+clocksource: timebase mult[7d0000] shift[22] registered
+Console: colour dummy device 80x25
+console [tty0] enabled
+console [hvc0] enabled
+console [hvc0] enabled
+allocated 524288 bytes of page_cgroup
+allocated 524288 bytes of page_cgroup
+please try 'cgroup_disable=memory' option if you don't want memory cgroups
+please try 'cgroup_disable=memory' option if you don't want memory cgroups
+pid_max: default: 32768 minimum: 301
+pid_max: default: 32768 minimum: 301
+Security Framework initialized
+Security Framework initialized
+AppArmor: AppArmor disabled by boot time parameter
+AppArmor: AppArmor disabled by boot time parameter
+Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes)
+Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes)
+Inode-cache hash table entries: 65536 (order: 3, 524288 bytes)
+Inode-cache hash table entries: 65536 (order: 3, 524288 bytes)
+Mount-cache hash table entries: 4096
+Mount-cache hash table entries: 4096
+Initializing cgroup subsys cpuacct
+Initializing cgroup subsys cpuacct
+Initializing cgroup subsys memory
+Initializing cgroup subsys memory
+Initializing cgroup subsys devices
+Initializing cgroup subsys devices
+Initializing cgroup subsys freezer
+Initializing cgroup subsys freezer
+Initializing cgroup subsys net_cls
+Initializing cgroup subsys net_cls
+Initializing cgroup subsys blkio
+Initializing cgroup subsys blkio
+Initializing cgroup subsys perf_event
+Initializing cgroup subsys perf_event
+POWER7 performance monitor hardware support registered
+POWER7 performance monitor hardware support registered
+Brought up 1 CPUs
+Brought up 1 CPUs
+Enabling Asymmetric SMT scheduling
+Enabling Asymmetric SMT scheduling
+devtmpfs: initialized
+devtmpfs: initialized
+print_constraints: dummy: 
+print_constraints: dummy: 
+NET: Registered protocol family 16
+NET: Registered protocol family 16
+IBM eBus Device Driver
+IBM eBus Device Driver
+nvram: No room to create ibm,rtas-log partition, deleting any obsolete OS partitions...
+nvram: No room to create ibm,rtas-log partition, deleting any obsolete OS partitions...
+nvram: Failed to find or create ibm,rtas-log partition, err -28
+nvram: Failed to find or create ibm,rtas-log partition, err -28
+nvram: No room to create lnx,oops-log partition, deleting any obsolete OS partitions...
+nvram: No room to create lnx,oops-log partition, deleting any obsolete OS partitions...
+nvram: Failed to find or create lnx,oops-log partition, err -28
+nvram: Failed to find or create lnx,oops-log partition, err -28
+SUSE Linux
+#1 SMP Wed Jan 2CPU Hotplug not supported by firmware - disabling.
+CPU Hotplug not supported by firmware - disabling.
+PCI: Probing PCI hardware
+PCI: Probing PCI hardware
+vmap allocation for size 2376249136786767872 failed: use vmalloc=<size> to increase size.
+vmap allocation for size 2376249136786767872 failed: use vmalloc=<size> to increase size.
+PCI: Memory resource 0 not set for host bridge /pci@800000020000001,0 (domain 0)
+PCI: Memory resource 0 not set for host bridge /pci@800000020000001,0 (domain 0)
+pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:00.0 dn=/pci@800000020000001,0/ethernet@0
+pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:00.0 dn=/pci@800000020000001,0/ethernet@0
+pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:01.0 dn=/pci@800000020000001,0/scsi@1
+pci_dma_dev_setup_pSeriesLP: no DMA window found for pci dev=0000:00:01.0 dn=/pci@800000020000001,0/scsi@1
+PCI: Cannot allocate resource region 0 of device 0000:00:00.0, will remap
+PCI: Cannot allocate resource region 0 of device 0000:00:00.0, will remap
+PCI: Cannot allocate resource region 6 of device 0000:00:00.0, will remap
+PCI: Cannot allocate resource region 6 of device 0000:00:00.0, will remap
+PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
+PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
+opal: Node not found
+opal: Node not found
+bio: create slab <bio-0> at 0
+bio: create slab <bio-0> at 0
+vgaarb: loaded
+vgaarb: loaded
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver hub
+usbcore: registered new interface driver hub
+usbcore: registered new device driver usb
+usbcore: registered new device driver usb
+NetLabel: Initializing
+NetLabel: Initializing
+NetLabel:  domain hash size = 128
+NetLabel:  domain hash size = 128
+NetLabel:  protocols = UNLABELED CIPSOv4
+NetLabel:  protocols = UNLABELED CIPSOv4
+NetLabel:  unlabeled traffic allowed by default
+NetLabel:  unlabeled traffic allowed by default
+Switching to clocksource timebase
+Switching to clocksource timebase
+NET: Registered protocol family 2
+NET: Registered protocol family 2
+IP route cache hash table entries: 8192 (order: 0, 65536 bytes)
+IP route cache hash table entries: 8192 (order: 0, 65536 bytes)
+TCP established hash table entries: 32768 (order: 3, 524288 bytes)
+TCP established hash table entries: 32768 (order: 3, 524288 bytes)
+TCP bind hash table entries: 32768 (order: 3, 524288 bytes)
+TCP bind hash table entries: 32768 (order: 3, 524288 bytes)
+TCP: Hash tables configured (established 32768 bind 32768)
+TCP: Hash tables configured (established 32768 bind 32768)
+TCP reno registered
+TCP reno registered
+UDP hash table entries: 2048 (order: 0, 65536 bytes)
+UDP hash table entries: 2048 (order: 0, 65536 bytes)
+UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
+UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
+NET: Registered protocol family 1
+NET: Registered protocol family 1
+Unpacking initramfs...
+Unpacking initramfs...
+Freeing initrd memory: 5696k freed
+Freeing initrd memory: 5696k freed
+rtasd: No event-scan on system
+rtasd: No event-scan on system
+rtas_flash: no firmware flash support
+rtas_flash: no firmware flash support
+IOMMU table initialized, virtual merging enabled
+IOMMU table initialized, virtual merging enabled
+vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable
+vio 30000000: Warning: IOMMU dma not supported: mask 0xffffffffffffffff, table unavailable
+HugeTLB registered 16 MB page size, pre-allocated 0 pages
+HugeTLB registered 16 MB page size, pre-allocated 0 pages
+VFS: Disk quotas dquot_6.5.2
+VFS: Disk quotas dquot_6.5.2
+Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
+Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
+msgmni has been set to 1992
+msgmni has been set to 1992
+Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
+Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
+io scheduler noop registered
+io scheduler noop registered
+io scheduler deadline registered
+io scheduler deadline registered
+io scheduler cfq registered (default)
+io scheduler cfq registered (default)
+pci_hotplug: PCI Hot Plug PCI Core version: 0.5
+pci_hotplug: PCI Hot Plug PCI Core version: 0.5
+rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
+rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
+rpadlpar_io_init: partition not DLPAR capable
+rpadlpar_io_init: partition not DLPAR capable
+Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
+pmac_zilog: 0.6 (Benjamin Herrenschmidt <email address hidden>)
+pmac_zilog: 0.6 (Benjamin Herrenschmidt <email address hidden>)
+Fixed MDIO Bus: probed
+Fixed MDIO Bus: probed
+arcnet loaded.
+arcnet loaded.
+ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
+ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
+mousedev: PS/2 mouse device common for all mice
+mousedev: PS/2 mouse device common for all mice
+EDAC MC: Ver: 2.1.0
+EDAC MC: Ver: 2.1.0
+usbcore: registered new interface driver usbhid
+usbcore: registered new interface driver usbhid
+usbhid: USB HID core driver
+usbhid: USB HID core driver
+TCP cubic registered
+TCP cubic registered
+NET: Registered protocol family 10
+NET: Registered protocol family 10
+NET: Registered protocol family 15
+NET: Registered protocol family 15
+lib80211: common routines for IEEE802.11 drivers
+lib80211: common routines for IEEE802.11 drivers
+Registering the dns_resolver key type
+Registering the dns_resolver key type
+libceph: loaded (mon/osd proto 15/24, osdmap 5/6 5/6)
+libceph: loaded (mon/osd proto 15/24, osdmap 5/6 5/6)
+turn off boot console udbg0
+turn off boot console udbg0
+registered taskstats version 1
+/home/abuild/rpmbuild/BUILD/kernel-ppc64-3.2.0/linux-3.2/drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
+Freeing unused kernel memory: 6272k freed
+doing fast boot
+device-mapper: uevent: version 1.0.3
+device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: <email address hidden>
+SCSI subsystem initialized
+alua: device handler registered
+rdac: device handler registered
+hp_sw: device handler registered
+emc: device handler registered
+Creating device nodes with udev
+udevd[78]: starting version 173
+virtio-pci 0000:00:00.0: device not available (can't reserve [io  0x0000-0x001f])
+virtio-pci: probe of 0000:00:00.0 failed with error -22
+virtio-pci 0000:00:01.0: device not available (can't reserve [io  0x0000-0x003f])
+virtio-pci: probe of 0000:00:01.0 failed with error -22
+udevd[98]: failed to execute '/etc/sysconfig/network/scripts/ifup-sysctl' '/etc/sysconfig/network/scripts/ifup-sysctl lo -o hotplug': No such file or directory
+
+mount: devpts already mounted or /dev/pts busy
+mount: according to mtab, devpts is already mounted on /dev/pts
+Boot logging started on /dev/hvc0(/dev/console) at Mon Mar 26 09:55:36 2012
+md: linear personality registered for level -1
+  Volume group "system" not found
+  Volume group "system" not found
+resume device  not found (ignoring)
+Waiting for device /dev/mapper/system-root to appear:   Reading all physical volumes.  This may take a while...
+  No volume groups found
+  Volume group "system" not found
+  Volume group "system" not found
+  Reading all physical volumes.  This may take a while...
+
+[...no virtio-pci block device found, so above scan loops...]
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/966316 b/results/classifier/gemma3:12b/boot/966316
new file mode 100644
index 000000000..4a5365d60
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/966316
@@ -0,0 +1,12 @@
+
+Can't load Android VBOX image or even linux test image as well
+
+Can't load Android X86 ICS 4.0 VBOX image.
+It worked with previous version before adding /qemu/hw/pc_sysfw.c file ( tested with version 1.0 ). 
+
+x86_64-softmmu# ./qemu-system-x86_64 ~/kvm-test-image/x86-linux-0.2.img
+qemu: PC system firmware (pflash) must be a multiple of 0x1000
+
+In QEMU website (http://wiki.qemu.org/Testing), there is a test image for linux
+but, new version can't load the image as well because of upper error.
+linux-0.2.img.bz2 (8 MB) 	Small Linux disk image containing a 2.6.20 Linux kernel, X11 and various utilities to test QEMU
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/boot/977 b/results/classifier/gemma3:12b/boot/977
new file mode 100644
index 000000000..41a35734f
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/977
@@ -0,0 +1,2 @@
+
+QEMU 6.2, windows 98 doesn't shutdown properly
diff --git a/results/classifier/gemma3:12b/boot/992 b/results/classifier/gemma3:12b/boot/992
new file mode 100644
index 000000000..be81d78db
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/992
@@ -0,0 +1,21 @@
+
+qemu-system-riscv64: Some ROM regions are overlapping When memory set <= 16
+Description of problem:
+
+Steps to reproduce:
+1. Build the qemu
+2. run `./build/riscv64-softmmu/qemu-system-riscv64 --nographic -machine virt -m 16`
+3. got error message:
+```
+qemu-system-riscv64: Some ROM regions are overlapping
+These ROM regions might have been loaded by direct user request or by default.
+They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory.
+Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses.
+
+The following two regions overlap (in the memory address space):
+  /home/shiroko/Developments/qemu/build/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin (addresses 0x0000000080000000 - 0x0000000080019b50)
+  fdt (addresses 0x0000000080000000 - 0x0000000080100000)
+```
+Additional information:
+Using `./build/riscv64-softmmu/qemu-system-riscv64 --nographic -machine virt -m 17` could bootup and seen OpenSBI messages.
+This problem appears on qemu-system-riscv32 too.
diff --git a/results/classifier/gemma3:12b/boot/995758 b/results/classifier/gemma3:12b/boot/995758
new file mode 100644
index 000000000..590a770c4
--- /dev/null
+++ b/results/classifier/gemma3:12b/boot/995758
@@ -0,0 +1,10 @@
+
+Possibly inaccurate statement in PC Platform Docs
+
+The documentation at:
+
+http://wiki.qemu.org/Documentation/Platforms/PC
+
+Contains the statement that the processor, after reset, executes code starting from address 0xFFFFF, corresponding to the last byte of the single megabyte of memory in the old 8086 address range.
+
+From my recollection of working in the microcomputer industry in the late 1980's, execution actually starts in real mode at the start of the last 16 bytes of addressable memory, at 0xFFFF0.  Think about it - if it's the last byte there's no room for an address operand to accompany a 1-byte opcode.
\ No newline at end of file
author	Christian Krinitsin <mail@krinitsin.com>	2025-07-03 07:27:52 +0000
committer	Christian Krinitsin <mail@krinitsin.com>	2025-07-03 07:27:52 +0000
commit	d0c85e36e4de67af628d54e9ab577cc3fad7796a (patch)
tree	f8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/gemma3:12b/boot
parent	7f4364274750eb8cb39a3e7493132fca1c01232e (diff)
download	qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip