summary refs log tree commit diff stats
path: root/results/classifier/deepseek-2-tmp/output/boot
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:34:26 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:35:44 +0000
commit25f8033d556aa17afaea4a5196ea7a69fe248320 (patch)
tree0f056db167683be54ea1e5e72d29d6069af55e7d /results/classifier/deepseek-2-tmp/output/boot
parent8e6da29e4ee5fc14bc1cc816a24f21271f14090d (diff)
downloadqemu-analysis-25f8033d556aa17afaea4a5196ea7a69fe248320.tar.gz
qemu-analysis-25f8033d556aa17afaea4a5196ea7a69fe248320.zip
add new temporary deepseek-r1:14b results
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/boot')
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/10120236
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/10138888
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/104208410
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/10778068
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/112013
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/112249247
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/113175724
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/126055517
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/1268279144
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/127394412
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/131466745
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/133185916
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/135872216
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/136346711
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/14351016
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/147345110
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/14768004
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/149671235
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/151213429
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/158622928
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/158911
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/158925717
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/159079647
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/159802923
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/159921423
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/161434840
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/162928222
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/163820
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/163939424
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/165306330
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/16952868
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/169857457
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/17165106
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/171770817
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/172392718
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/173267989
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/173565341
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/173719437
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/17378825
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/17378837
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/17434414
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/17560804
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/17764868
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/1781463100
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/180152
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/180496110
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18109569
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18117826
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/181188814
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/181434331
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/181537134
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18192894
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/182315237
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/182399812
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/182520726
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/182957654
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18314777
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18361364
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/183734735
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/184071912
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/184463545
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18492344
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/185219625
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18530834
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/185378137
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/185457712
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/185500226
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/185714316
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18599
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/18591066
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/185965643
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/186091414
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/187091112
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/188124910
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/188267152
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/189254024
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/190615616
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/190690513
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/19079534
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/190841614
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/191579411
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/192349728
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/192541769
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/192605216
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/196230
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/19952
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/2062
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/20908
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/21092
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/223424
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/223558
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/22802
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/23659
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/268649
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/27009
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/284022
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/28472
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/29402
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/3662
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/3935696
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/4252
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/4362
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/552
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/55154596
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/58617513
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/58873520
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/5887484
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/5982
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/59912
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/6223679
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/62385214
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/6279828
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/63965122
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/67011
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/6972
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/72346023
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/76095621
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/81864779
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/82577615
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/83083314
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/8336587
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/96631612
-rw-r--r--results/classifier/deepseek-2-tmp/output/boot/9946
123 files changed, 2629 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1012023 b/results/classifier/deepseek-2-tmp/output/boot/1012023
new file mode 100644
index 000000000..a1fa043e6
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1012023
@@ -0,0 +1,6 @@
+
+Windows 7 bluescreen STOP: 00000005D
+
+Hello, with installed windows, or with install cd I have a blue screen (crash) after the first windows logo, see the screenshot.
+
+Thanks to fix it.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1013888 b/results/classifier/deepseek-2-tmp/output/boot/1013888
new file mode 100644
index 000000000..4b6247ac4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1042084 b/results/classifier/deepseek-2-tmp/output/boot/1042084
new file mode 100644
index 000000000..a610a1774
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1077806 b/results/classifier/deepseek-2-tmp/output/boot/1077806
new file mode 100644
index 000000000..44ce0d20f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1077806
@@ -0,0 +1,8 @@
+
+Integrate Virtualbox/Qemu Guest booting as a desktop environment listing (request)
+
+I had seen this new way to install Chromium OS and "boot" it using LightDM's session select menu, and it made me think of an idea:
+
+What if you were able to boot virtual machines in the same manner? It would simplify the Ubuntu user's life GREATLY if they had easy access to a Windows VM that can synchronize their files to and fro (Guest additions) and not require a reboot to use it. Modern computers have more than enough power to do something like this, and it should be even easier if the system is using a dedicated virtual machine environment rather than a full blown desktop.
+
+I think this would make using Ubuntu a LOT less of a hassle for the new user who came from Windows :)
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1120 b/results/classifier/deepseek-2-tmp/output/boot/1120
new file mode 100644
index 000000000..a0b9e195a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1122492 b/results/classifier/deepseek-2-tmp/output/boot/1122492
new file mode 100644
index 000000000..ff8af3c84
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1131757 b/results/classifier/deepseek-2-tmp/output/boot/1131757
new file mode 100644
index 000000000..9ea4082bc
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1260555 b/results/classifier/deepseek-2-tmp/output/boot/1260555
new file mode 100644
index 000000000..41be0c80e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1268279 b/results/classifier/deepseek-2-tmp/output/boot/1268279
new file mode 100644
index 000000000..5c1e8e1b3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1268279
@@ -0,0 +1,144 @@
+
+Windows 7 x86 does not start on 1.7.50 from git
+
+I have "Debian 7.2 x64". 
+
+Install last QEMU from git:
+
+aptitude install git gcc make autoconf libglib2.0-dev libcurl4-gnutls-dev libpixman-1-dev libcap-dev  libaio-dev libcap-ng-dev libjpeg8-dev libpng12-dev libssh2-1-dev uuid-dev
+
+#cd /usr/src
+#git clone git://git.qemu.org/qemu.git
+#cd qemu
+# ./configure --prefix=/usr  --sysconfdir=/etc --target-list=x86_64-softmmu  --enable-kvm
+Install prefix    /usr
+BIOS directory    /usr/share/qemu
+binary directory  /usr/bin
+library directory /usr/lib
+libexec directory /usr/libexec
+include directory /usr/include
+config directory  /etc
+local state directory   /usr/var
+Manual directory  /usr/share/man
+ELF interp prefix /usr/gnemul/qemu-%M
+Source path       /usr/src/qemu
+C compiler        cc
+Host C compiler   cc
+C++ compiler      c++
+Objective-C compiler cc
+ARFLAGS           rv
+CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
+QEMU_CFLAGS       -Werror -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing  -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1    -I/usr/include/libpng12     -I/usr/include/pixman-1
+LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g
+make              make
+install           install
+python            python -B
+smbd              /usr/sbin/smbd
+host CPU          x86_64
+host big endian   no
+target list       x86_64-softmmu
+tcg debug enabled no
+gprof enabled     no
+sparse enabled    no
+strip binaries    yes
+profiler          no
+static build      no
+-Werror enabled   yes
+pixman            system
+SDL support       yes
+GTK support       no
+curses support    no
+curl support      yes
+mingw32 support   no
+Audio drivers     oss
+Block whitelist (rw)
+Block whitelist (ro)
+VirtFS support    yes
+VNC support       yes
+VNC TLS support   yes
+VNC SASL support  no
+VNC JPEG support  yes
+VNC PNG support   yes
+VNC WS support    yes
+xen support       no
+brlapi support    no
+bluez  support    no
+Documentation     yes
+GUEST_BASE        yes
+PIE               yes
+vde support       no
+netmap support    no
+Linux AIO support yes
+ATTR/XATTR support yes
+Install blobs     yes
+KVM support       yes
+RDMA support      no
+TCG interpreter   no
+fdt support       no
+preadv support    yes
+fdatasync         yes
+madvise           yes
+posix_madvise     yes
+sigev_thread_id   yes
+uuid support      yes
+libcap-ng support yes
+vhost-net support yes
+vhost-scsi support yes
+Trace backend     nop
+Trace output file trace-<pid>
+spice support     no (/)
+rbd support       no
+xfsctl support    no
+nss used          no
+libusb            no
+usb net redir     no
+GLX support       yes
+libiscsi support  no
+build guest agent yes
+QGA VSS support   no
+seccomp support   no
+coroutine backend ucontext
+coroutine pool    yes
+GlusterFS support no
+virtio-blk-data-plane yes
+gcov              gcov
+gcov enabled      no
+TPM support       no
+libssh2 support   yes
+TPM passthrough   no
+QOM debugging     yes
+vhdx              yes
+#make && make install
+
+QEMU is successfully builded and installed:
+
+# /usr/bin/qemu-system-x86_64 --version
+QEMU emulator version 1.7.50, Copyright (c) 2003-2008 Fabrice Bellard
+
+Create virtual HDD:
+
+# qemu-img create -f qcow2 /kvm/vm/test.img 50G
+Formatting '/kvm/vm/test.img', fmt=qcow2 size=53687091200 encryption=off cluster_size=65536 lazy_refcounts=off
+
+Start virtual machine:
+
+ # /usr/bin/qemu-system-x86_64 -cpu qemu64 -M pc -smp 1 -m 1024 -monitor tcp:127.0.0.1:4444,server,nowait -drive file=/kvm/vm/test.img,cache=writeback,aio=native -boot order=dc,menu=on -enable-kvm -vnc 127.0.0.1:14 -localtime -no-hpet -rtc-td-hack -global kvm-pit.lost_tick_policy=discard -daemonize -usb -device usb-tablet,id=input0 -runas kvm
+
+Connect ISO image:
+
+# nc 127.0.0.1 4444
+QEMU 1.7.50 monitor - type 'help' for more information
+(qemu) change ide1-cd0 http://iso.vpsnow.ru/windows/7/ru_windows_7_professional_with_sp1_x86_dvd.iso
+change ide1-cd0 http://someiso.host.com/ru_windows_7_professional_with_sp1_x86_dvd.iso
+(qemu)
+
+Open NVC console to VM, reboot and boot (F12) from connected ISO.
+Windows installation start and successfully goes to first reboot.
+
+==========================================
+After reboot it hangs on "Starting windows" with 100%  load on one of CPU cores for many hours.
+==========================================
+
+Other Windows OS (XP, Server 2003, Server 2008 R2) are installed and work good.
+
+Is this a QEMU BUG? Could you please try reproduce it?
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1273944 b/results/classifier/deepseek-2-tmp/output/boot/1273944
new file mode 100644
index 000000000..b602f48e3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1314667 b/results/classifier/deepseek-2-tmp/output/boot/1314667
new file mode 100644
index 000000000..5305b75ca
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1331859 b/results/classifier/deepseek-2-tmp/output/boot/1331859
new file mode 100644
index 000000000..9e487786a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1331859
@@ -0,0 +1,16 @@
+
+QEMU kernel panic on Windows with arithmetic syntax error
+
+During attempts to bring-up QEMU 64-bit ARM support I discovered a kernel panics that only occur on Windows but work properly on Linux.
+
+The issue can be reproduced by running the following command line:
+
+$ ./arm-softmmu/qemu-system-arm -M versatilepb -kernel $IMAGES/vmlinuz-3.2.0-4-versatile -initrd $IMAGES/initrd.img-3.2.0-4-versatile -hda $IMAGES/debian_wheezy_armel_standard.qcow2 -append "root=/dev/sda1"
+
+where $IMAGES is the location where the images are downloaded from http://people.debian.org/~aurel32/qemu/armel/.
+
+This was reproduced with both a custom built QEMU as well as the QEMU image installed by http://qemu.weilnetz.de/w32/qemu_w32-setup-20140617.exe.
+
+The same command line runs properly on Linux using a custom built QEMU.
+
+The Windows versions of QEMU do appear to work properly using the arm-test images available on qemu.org.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1358722 b/results/classifier/deepseek-2-tmp/output/boot/1358722
new file mode 100644
index 000000000..32727f567
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1358722
@@ -0,0 +1,16 @@
+
+latest acpi commits causes memory allocation fault in macosx
+
+qemu release 2.1.0
+
+Hi,
+I've found a regression on MacOSX guest (10.9.4) after merging the following commits 
+
+18045fb9f457a0f0cba2bd113c748a2dcb4ed39e pc: future-proof migration-compatibility of ACPI tables
+868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi migration limits
+
+The migration limits make x86 chameleon bootloader generate a memory allocation error with 0xdeadbeef address at line 899 in source file:
+
+http://forge.voodooprojects.org/p/chameleon/source/tree/2360/branches/Bungo/i386/libsaio/acpi_patcher.c
+
+I've not tried to recompile chameleon yet.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1363467 b/results/classifier/deepseek-2-tmp/output/boot/1363467
new file mode 100644
index 000000000..c2cdb0284
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1435101 b/results/classifier/deepseek-2-tmp/output/boot/1435101
new file mode 100644
index 000000000..ea0ed9af3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1473451 b/results/classifier/deepseek-2-tmp/output/boot/1473451
new file mode 100644
index 000000000..4c2be2ae8
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1476800 b/results/classifier/deepseek-2-tmp/output/boot/1476800
new file mode 100644
index 000000000..8c4a3e6ba
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1496712 b/results/classifier/deepseek-2-tmp/output/boot/1496712
new file mode 100644
index 000000000..b6d9f20b8
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1512134 b/results/classifier/deepseek-2-tmp/output/boot/1512134
new file mode 100644
index 000000000..b2db69a1f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1586229 b/results/classifier/deepseek-2-tmp/output/boot/1586229
new file mode 100644
index 000000000..42bfb0dc2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1589 b/results/classifier/deepseek-2-tmp/output/boot/1589
new file mode 100644
index 000000000..703a8996b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1589
@@ -0,0 +1,11 @@
+
+Crash when using qemu 8.0.0 version tcg mode
+Description of problem:
+Can I no longer use qemu in tcg mode?
+When operating in tcg mode in all versions of 8.0.0, a crash occurs on the booting screen and the window closes (the window stops responding before closing).
+Steps to reproduce:
+1. Run qemu with -accel tcg option
+2. enter the boot screen
+3. The screen freezes and the window closes after a few seconds (at which point it becomes unresponsive)
+Additional information:
+I have not checked whether the same symptom occurs in Linux, and it occurs in all versions of 8.0.0 for Windows.
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1589257 b/results/classifier/deepseek-2-tmp/output/boot/1589257
new file mode 100644
index 000000000..dc536a4e6
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1590796 b/results/classifier/deepseek-2-tmp/output/boot/1590796
new file mode 100644
index 000000000..2ff87d715
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1598029 b/results/classifier/deepseek-2-tmp/output/boot/1598029
new file mode 100644
index 000000000..69de96b10
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1598029
@@ -0,0 +1,23 @@
+
+failed to boot a customized kernel if emulating Broadwell/Skylake
+
+Hardware: X86-64, Intel(R) Core(TM) i7-6500U( Skylake)
+OS: Linux Mint 18
+Host Kernel: 4.5.7 + PaX/Grsecurity
+Qemu: QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.2)
+
+[Reproduction Steps]
+1, Install a Debian 8 in the guest
+2, Install a customized kernel( using same config to Debian 8)
+3, Reboot:
+qemu-system-x86_64 -hda debian8-test.img -boot d  -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu Broadwell -smp 2
+
+or
+
+qemu-system-x86_64 -hda debian8-test.img -boot d  -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu host -smp 2
+
+[Actual Result]  
+kernel panic or can't login in the system
+
+[Workaround]
+qemu-system-x86_64 -hda debian8-test.img -boot d  -m 2048 -enable-kvm -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu Haswell -smp 2
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1599214 b/results/classifier/deepseek-2-tmp/output/boot/1599214
new file mode 100644
index 000000000..b0dcc9d0f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1614348 b/results/classifier/deepseek-2-tmp/output/boot/1614348
new file mode 100644
index 000000000..611d620b3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1614348
@@ -0,0 +1,40 @@
+
+qemu-arm core dumped for no entry symbol programe
+
+Hi qemu developers,
+
+Environment:
+* Fedora 24 x86_64
+* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard
+* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi
+* glibc-arm-linux-gnu-devel-2.23
+
+very simple hello.c:
+
+#include <stdio.h>
+
+int main(int argc, char *argv[]) 
+{
+    printf("Hello World\n");
+
+    return 0;
+}
+
+arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc
+
+/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc
+
+qemu-arm -L /usr/arm-linux-gnu ./a.out
+
+Hello World
+qemu: uncaught target signal 4 (Illegal instruction) - core dumped
+Illegal instruction
+
+But provided entry symbol: 
+
+arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc
+
+qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily!
+
+Regards,
+Leslie Zhai
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1629282 b/results/classifier/deepseek-2-tmp/output/boot/1629282
new file mode 100644
index 000000000..eba3c337e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1638 b/results/classifier/deepseek-2-tmp/output/boot/1638
new file mode 100644
index 000000000..e4bc7afbd
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1638
@@ -0,0 +1,20 @@
+
+BUG: Segmentation fault when -object memory-backend-file use readonly=on, prealloc=on together
+Description of problem:
+Segmentation Fault while booting VM.
+Steps to reproduce:
+1. set qemu boot params to `-object memory-backend-file,id=mem1,readonly=on,prealloc=on,mem-path=<any-img-file>,size=4G`
+2.
+3.
+Additional information:
+It might not be a bug, probably a feature.
+The reason of this segfault is:
+readonly would mmap the backend file using PROT_READ, make it readonly,
+but the prealloc=on would touch_pages the memory mmaped by the file.
+SO the segfault happens.
+
+But there is no docs about this segfault condition (the readonly and prealloc cannot be used together.)
+
+And maybe there is a way to solve this problem, I think.
+Use mmap the memory backend file to PROT_READ|PROT_WRITE at the beginnning, after touch_pages, then mprotect the memory.
+change the prot to readonly if required.
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1639394 b/results/classifier/deepseek-2-tmp/output/boot/1639394
new file mode 100644
index 000000000..7546f3d17
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1653063 b/results/classifier/deepseek-2-tmp/output/boot/1653063
new file mode 100644
index 000000000..d32909489
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1695286 b/results/classifier/deepseek-2-tmp/output/boot/1695286
new file mode 100644
index 000000000..848d18d0e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1698574 b/results/classifier/deepseek-2-tmp/output/boot/1698574
new file mode 100644
index 000000000..ab47936d3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1698574
@@ -0,0 +1,57 @@
+
+slow boot windows 7
+
+Hello,
+I have a nice working qemu with gpu passthrough setup.
+I pass through my nvidia gtx 880m.
+It boots in 4mins 18secs.
+
+If I remove the "-vga none" switch and allow qemu to create a vga adapter I can boot in 1min.
+
+Why does a normal boot with the nvidia card hang for 3mins (yes, the hd light just flickers for that long)?
+
+Nothing major but I'd like to know, especially if it can be fixed.
+
+I cannot leave -vga none turned on as the vga adapter grabs up resources and the nvidia card complains it cannot start due to lack of resources. I'd love to just add resources if possible and keep both cards running to get the 1min boot time.
+
+Here is my script:
+
+qemu-system-x86_64 -machine type=q35,accel=kvm -cpu host,kvm=off \
+-smp 8,sockets=1,cores=4,threads=2 \
+-bios /usr/share/seabios/bios.bin \
+-serial none \
+-parallel none \
+-vga none \
+-m 7G \
+-mem-prealloc \
+-balloon none \
+-rtc clock=host,base=localtime \
+-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
+-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
+-device virtio-scsi-pci,id=scsi \
+-drive id=disk0,if=virtio,cache=none,format=raw,file=/home/bob/qemu/windows7.img \
+-drive file=/home/bob/qemu/qemu2/virtio-win-0.1.126.iso,id=isocd,format=raw,if=none -device scsi-cd,drive=isocd \
+-netdev type=tap,id=net0,ifname=tap0 \
+-device virtio-net-pci,netdev=net0,mac=00:16:3e:00:01:01 \
+-usbdevice host:413c:a503 \
+-usbdevice host:13fe:3100 \
+-usbdevice host:0bc2:ab21 \
+-boot menu=on \
+-boot order=c
+
+
+
+Here are my specs:
+
+System:    Host: MSI-GT70-2PE Kernel: 4.8.0-51-generic x86_64 (64 bit gcc: 5.4.0)
+           Desktop: Cinnamon 3.2.7 (Gtk 3.18.9) Distro: Linux Mint 18.1 Serena
+Machine:   Mobo: Micro-Star model: MS-1763 v: REV:0.C Bios: American Megatrends v: E1763IMS.51B date: 01/29/2015
+CPU:       Quad core Intel Core i7-4810MQ (-HT-MCP-) cache: 6144 KB
+           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 22348
+           clock speeds: max: 2801 MHz 1: 2801 MHz 2: 800 MHz 3: 900 MHz 4: 900 MHz 5: 900 MHz 6: 1700 MHz
+           7: 800 MHz 8: 900 MHz
+Graphics:  Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0
+           Card-2: NVIDIA GK104M [GeForce GTX 880M] bus-ID: 01:00.0
+           Display Server: X.Org 1.18.4 driver: nvidia Resolution: 1920x1080@60.00hz
+           GLX Renderer: GeForce GTX 880M/PCIe/SSE2 GLX Version: 4.5.0 NVIDIA 375.66
+Direct Rendering: Yes
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1716510 b/results/classifier/deepseek-2-tmp/output/boot/1716510
new file mode 100644
index 000000000..357410c46
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1717708 b/results/classifier/deepseek-2-tmp/output/boot/1717708
new file mode 100644
index 000000000..a2affd37f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1717708
@@ -0,0 +1,17 @@
+
+QEMU aarch64 can't run Windows ARM64 iso's
+
+Hi,
+recently Windows ARM64 ISOs have been posted on the internet..
+just checked with latest QEMU 2.10 release from 
+https://qemu.weilnetz.de/w64/qemu-w64-setup-20170830.exe 
+"h:\qemu\qemu-system-aarch64.exe" -boot d -cdrom h:\iso\16353.1000.170825-1423.RS_PRERELEASE_CLIENTPRO_OEMRET_ARM64FRE_ES-ES.ISO -m 2048 -cpu cortex-a57 -smp 1 -machine virt
+seems no video output..
+checked various machine options for example versatilepb (says guest has not initialized the guest)..
+
+so don't know if it's a QEMU bug or lacking feature but can support running Windows ARM64 builds (would be nice if you can add a Snapdragon835 machine type which is which first machines will be running..)
+
+
+note running a Windows x64 ISO with similar parameters works (removing -cpu and -machine as not needed)
+
+thanks..
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1723927 b/results/classifier/deepseek-2-tmp/output/boot/1723927
new file mode 100644
index 000000000..0e4d7debf
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1732679 b/results/classifier/deepseek-2-tmp/output/boot/1732679
new file mode 100644
index 000000000..9db8dcf17
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1735653 b/results/classifier/deepseek-2-tmp/output/boot/1735653
new file mode 100644
index 000000000..fe7fc2853
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1737194 b/results/classifier/deepseek-2-tmp/output/boot/1737194
new file mode 100644
index 000000000..5e2c44e76
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1737882 b/results/classifier/deepseek-2-tmp/output/boot/1737882
new file mode 100644
index 000000000..cd285cf38
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1737883 b/results/classifier/deepseek-2-tmp/output/boot/1737883
new file mode 100644
index 000000000..771739e85
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1743441 b/results/classifier/deepseek-2-tmp/output/boot/1743441
new file mode 100644
index 000000000..18fde92cc
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1756080 b/results/classifier/deepseek-2-tmp/output/boot/1756080
new file mode 100644
index 000000000..822a072c0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1756080
@@ -0,0 +1,4 @@
+
+QEMU does not provide non-Linux kernels with ATAGS structure on ARM targets
+
+This would be a useful feature. Many kernels, particularly hobbyist kernels, have support for ATAGS.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1776486 b/results/classifier/deepseek-2-tmp/output/boot/1776486
new file mode 100644
index 000000000..9859378ce
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1781463 b/results/classifier/deepseek-2-tmp/output/boot/1781463
new file mode 100644
index 000000000..66ef2d6a2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1781463
@@ -0,0 +1,100 @@
+
+qemu don't start *.abs firmware files
+
+Hello Devs,
+
+I'm here to report this bug/issue because i'm using Win64 Qemu but i can't start a *.abs firmware at normally this firmware is based in Linux Kernel and this type of firmware is made for STB Receivers,
+
+So this is all information i provide to get support.
+
+Files extracted by ( binwalk -e )
+
+
+Terminal output:
+
+# binwalk -e AMIKO_HD8150_2.4.43_emu.abs
+
+DECIMAL       HEXADECIMAL     DESCRIPTION
+
+--------------------------------------------------------------------------------
+196736        0x30080         LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 11883876 bytes
+3866752       0x3B0080        LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 3255512 bytes
+5636224       0x560080        LZMA compressed data, properties: 0x6C, dictionary size: 8388608 bytes, uncompressed size: 87904 bytes
+
+
+Files extracted with ALI TOOLS or Ali FirmwareDecriptor.
+
+Windows files output:
+
+Software used: Ali Main Code Decrypter 8.9
+
+Files unpacked:
+
+bootloader
+MemCfg
+maincode(AV)
+seecode
+default_lang
+cipluskey
+countryband
+logo_user
+logo_menu
+logo_radio
+logo_boot
+patch
+defaultdb(PRC)
+userdb(64+64)
+
+
+Terminal OUTPUT:
+
+# hexdump -C 
+
+part of file 
+
+
+00b51a30  00 00 00 00 4c 69 62 63  6f 72 65 20 76 65 72 73  |....Libcore vers|
+00b51a40  69 6f 6e 20 31 33 2e 31  36 2e 30 40 53 44 4b 34  |ion 13.16.0@SDK4|
+00b51a50  2e 30 66 61 2e 31 33 2e  31 36 5f 32 30 31 36 31  |.0fa.13.16_20161|
+00b51a60  30 31 39 28 67 63 63 20  76 65 72 73 69 6f 6e 20  |019(gcc version |
+00b51a70  33 2e 34 2e 34 20 6d 69  70 73 73 64 65 2d 36 2e  |3.4.4 mipssde-6.|
+00b51a80  30 36 2e 30 31 2d 32 30  30 37 30 34 32 30 29 28  |06.01-20070420)(|
+00b51a90  41 64 6d 69 6e 69 73 74  72 61 74 6f 72 40 20 46  |Administrator@ F|
+00b51aa0  72 69 2c 20 4a 75 6c 20  32 38 2c 20 32 30 31 37  |ri, Jul 28, 2017|
+00b51ab0  20 31 32 3a 35 33 3a 32  38 20 41 4d 29 0a 00 00  | 12:53:28 AM)...|
+00b51ac0  44 4d 58 5f 53 33 36 30  31 5f 30 00 00 a1 03 18  |DMX_S3601_0.....|
+
+
+When I use readelf it says files isn't an ELF file, so i can't run it like a kernel (Bootloader,Maincode, and etc. )
+
+so this is the cmd output when i use qemu Win64 (I don't whant to use linux to do the emulation about this *.abs extension firmware so please help me for win64 version from Qemu)
+
+CMD OUTPUT:
+
+ C:\Program Files\qemu>qemu-system-mips.exe -machine mips -cpu mips32r6-generic -drive file=C:\30080.bin,index=0,media=disk,format=raw
+
+qemu-system-mips.exe: warning: could not load MIPS bios 'mips_bios.bin'
+
+I also tried a lot of diferents qemu-system... and a lot of diferent configs like -machine -cpu -kernel -driver root= -PFLASH and etc... and nothing hapenned
+
+How can i reproduce this issue ? 
+Reply:. 
+
+Donwload *.abs firmware in amikoreceiver.com (only *.abs) and download AliDekompressor in http://www.satedu.cba.pl/
+
+Direct tools:
+
+FirmwareDecrypter_v8.9.zip :
+
+http://www.satedu.cba.pl/index.php?action=downloadfile&filename=FirmwareDecrypter_v8.9.zip&directory=Test%20Folder&
+
+Ali__tools_Console_v4.0__CRC_FIXER.rar :
+
+http://www.satedu.cba.pl/index.php?action=downloadfile&filename=Ali__tools_Console_v4.0__CRC_FIXER.rar&directory=Test%20Folder&
+
+
+so if Qemu can explain how can i fix this issue this can be highly helpfull.
+
+With my best regards,
+David Martins 
+Screamfox
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1801 b/results/classifier/deepseek-2-tmp/output/boot/1801
new file mode 100644
index 000000000..17b0657be
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1804961 b/results/classifier/deepseek-2-tmp/output/boot/1804961
new file mode 100644
index 000000000..eb26fd4e6
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1810956 b/results/classifier/deepseek-2-tmp/output/boot/1810956
new file mode 100644
index 000000000..5f952f240
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1811782 b/results/classifier/deepseek-2-tmp/output/boot/1811782
new file mode 100644
index 000000000..046f54914
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1811888 b/results/classifier/deepseek-2-tmp/output/boot/1811888
new file mode 100644
index 000000000..efb9104da
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1814343 b/results/classifier/deepseek-2-tmp/output/boot/1814343
new file mode 100644
index 000000000..16e8f1575
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1815371 b/results/classifier/deepseek-2-tmp/output/boot/1815371
new file mode 100644
index 000000000..322ff865e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1815371
@@ -0,0 +1,34 @@
+
+ SPICE session's connection_id's are not unique
+
+From: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920897
+
+=====
+
+When creating a virtual machine with qemu (e.g. via libvirt) including a SPICE server, the client_id of the SPICE session is not unique. For example, starting multiple virtual machines on the same libvirtd, the client_id is the same for all virtual machine's SPICE sessions.
+
+
+A description of the client_id can be found in
+
+https://www.spice-space.org/static/docs/spice_protocol.pdf under section 2.11. c) :
+
+
+"UINT32 connection_id - In case of a new session (i.e., channel type is RED_CHANNEL_MAIN) this field is set to zero, and in response the server will allocate session id and will send it via the RedLinkReply message. In case of all other channel types, this field will be equal to the allocated session id"
+
+
+The relevant code for generating client ids in libspice-server1 can be found here: https://gitlab.freedesktop.org/spice/spice/blob/v0.12.8/server/reds.c#L1614
+
+This uses rand() to generate the random id, but qemu (at least in the case of qemu-system-x86) fails to initialize the RNG seed (with e.g. srand()).
+
+
+The result is, that every SPICE session started (by e.g. libvirtd) has the same client_id. Usually, this is not a problem, but running something like a SPICE proxy, relying on the client_id to correctly route connections, this creates problems.
+
+
+Adding something like 'srand(time(NULL));' to qemu (in vl.c) solves this issue. Related (as seen in some VNC patches, e.g. 'CVE-2017-15124/04-ui-avoid-pointless-VNC-updates-if-framebuffer-isn-t-.patch/ui/vnc.c' ):  srand(time(NULL)+getpid()+getpid()*987654+rand());
+
+
+Tested on Debian 9.7 with kernel  4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux.
+
+
+
+=====
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1819289 b/results/classifier/deepseek-2-tmp/output/boot/1819289
new file mode 100644
index 000000000..43909d2be
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1823152 b/results/classifier/deepseek-2-tmp/output/boot/1823152
new file mode 100644
index 000000000..3acae5857
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1823998 b/results/classifier/deepseek-2-tmp/output/boot/1823998
new file mode 100644
index 000000000..d3876d114
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1825207 b/results/classifier/deepseek-2-tmp/output/boot/1825207
new file mode 100644
index 000000000..2e54b96c2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1829576 b/results/classifier/deepseek-2-tmp/output/boot/1829576
new file mode 100644
index 000000000..1c7ec73f3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1831477 b/results/classifier/deepseek-2-tmp/output/boot/1831477
new file mode 100644
index 000000000..285a31962
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1836136 b/results/classifier/deepseek-2-tmp/output/boot/1836136
new file mode 100644
index 000000000..5c9080ad7
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1837347 b/results/classifier/deepseek-2-tmp/output/boot/1837347
new file mode 100644
index 000000000..37e9aadd0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1837347
@@ -0,0 +1,35 @@
+
+guest userspace process core dump after raspi2 kernel boot
+
+Host info:
+==========
+x86-64, Ubuntu 18.04, QEMU 4.0.0 (downloaded tarball from main site)
+
+Guest info:
+===========
+ARM7l, Raspbian OS off the main raspberry pi site
+
+QEMU command:
+=============
+qemu-system-arm -M raspi2 -kernel bootpart/kernel7.img -dtb bootpart/bcm2709-rpi-2-b.dtb -drive file=2019-07-10-raspbian-buster.img,format=raw,if=sd -append "rw earlyprintk console=ttyAMA0,115200 fsck.repair=yes rootwait memtest=1 loglevel=8 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -serial stdio
+
+kernel7.img and bcm2709-rpi-2-b.dtb were obtained by the following commands:
+
+guestfish --ro -a 2019-07-10-raspbian-buster.img -m /dev/sda1
+><fs> copy-out / bootpart/
+><fs> quit
+
+Output:
+=======
+
+https://pastebin.com/fL1eXhV0
+
+References:
+===========
+https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/
+https://translatedcode.wordpress.com/2018/04/25/debian-on-qemus-raspberry-pi-3-model/
+
+
+The core dump error can occur at both times, before logging in and after logging in, in this case I have given the output after logging in to show the initial processes running.
+
+Also please let me know if I using any kernel flags incorrectly
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1840719 b/results/classifier/deepseek-2-tmp/output/boot/1840719
new file mode 100644
index 000000000..3e6477503
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1844635 b/results/classifier/deepseek-2-tmp/output/boot/1844635
new file mode 100644
index 000000000..d5e9f9718
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1844635
@@ -0,0 +1,45 @@
+
+qemu bug where load linux kernel
+
+i found a qemu bug ,when the qemu start and parse the kernel file .
+
+This vulnerability can be exploited.
+
+thanks
+
+/****
+
+
+(gdb) set args -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -machine accel=kvm -m 2048  -smp 2 -cpu host -machine kernel_irqchip=split -kernel poc1
+(gdb) r
+Starting program: /usr/bin/qemu-system-x86_64 -nodefaults -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc none -serial stdio -device pci-testdev -machine accel=kvm -m 2048  -smp 2 -cpu host -machine kernel_irqchip=split -kernel ./poc/poc1
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+[New Thread 0x7fffe9a03700 (LWP 30066)]
+[New Thread 0x7fffe9202700 (LWP 30068)]
+[New Thread 0x7fffe8a01700 (LWP 30069)]
+
+Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
+__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:249
+249	../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
+(gdb) bt
+#0  0x00007ffff2390b1f in __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:249
+#1  0x00005555559ebdcf in rom_copy ()
+#2  0x00005555558dd1b3 in load_multiboot ()
+#3  0x00005555558de1c3 in  ()
+#4  0x00005555558e19d1 in pc_memory_init ()
+#5  0x00005555558e4ee3 in  ()
+#6  0x00005555559e8500 in machine_run_board_init ()
+#7  0x0000555555834959 in main ()
+(gdb) c
+Continuing.
+Couldn't get registers: No such process.
+Couldn't get registers: No such process.
+(gdb) [Thread 0x7fffe8a01700 (LWP 30069) exited]
+[Thread 0x7fffe9202700 (LWP 30068) exited]
+[Thread 0x7fffe9a03700 (LWP 30066) exited]
+
+Program terminated with signal SIGSEGV, Segmentation fault.
+The program no longer exists.
+
+***/
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1849234 b/results/classifier/deepseek-2-tmp/output/boot/1849234
new file mode 100644
index 000000000..36b787731
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1852196 b/results/classifier/deepseek-2-tmp/output/boot/1852196
new file mode 100644
index 000000000..19d805c1e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1853083 b/results/classifier/deepseek-2-tmp/output/boot/1853083
new file mode 100644
index 000000000..dc1a6fd62
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1853781 b/results/classifier/deepseek-2-tmp/output/boot/1853781
new file mode 100644
index 000000000..4014069f1
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1853781
@@ -0,0 +1,37 @@
+
+Baremetal kernel built from assembly runs multiple times
+
+QEMU version: 4.1.0.
+
+Full command used to launch: qemu-system-arm -machine raspi2 -kernel main
+
+(Technically, the first term of the command is actually "~/Applications/QEMU/qemu-4.1.0/build/arm-softmmu/qemu-system-arm", but I shortened it for readability.)
+
+Host information: Running debian 9.9 on a 64-bit x86 processor (Intel i5-2520M).
+
+Guest information: No operating system. I'm providing my own kernel, which I assembled from a 60-line ARM assembly program using arm-none-eabi-as and then linked with arm-none-eabi-ld, both version 2.28-5+9+b3.
+
+Additional details: To view the screen output of the program, I am using vncviewer version 6.19.1115 (r42122). All of the above software packages were installed as debian packages using apt, except for QEMU, which I built from source after downloading from the official website.
+
+.
+
+The issue here is that I have written a program in assembly and it isn't doing what I expect it to when I emulate it. Here's a summary of the code:
+
+1) Read a number from zero-initialized memory.
+
+2) Add one to the number and write it back.
+
+3) Use the number to determine a screen location to write to.
+
+4) Use the number to determine what color to write.
+
+5) Write 4000 half-words to the screen starting at that offset and using that color. This should result in a stripe across the whole screen that's about 6 pixels tall.
+
+The expected behavior is that *one* stripe should appear on the screen in a single color. However, the actual behavior is that up to *four* stripes appear, each in a different color. Furthermore, if I comment out the line that writes the incremented counter back to memory, then only one stripe will appear.
+
+I will also note that the Raspberry Pi 2, which is the system I'm emulating, has four cores. What I suspect is going on here is that my code is being loaded onto all four cores of the emulated machine. I couldn't find anything about this anywhere in the documentation, and it strikes me as bug.
+
+I have attached the assmebly code that I'm using, as well as a short makefile. Since I can only add one attachment to this report, I've combined the two into a single text file and labeled each. After separating the two into two files, you will need to change the first line of the makefile to point to your installation of qemu-system-arm v4.1.0. After that, type "make run" to run the program.
+
+Thanks in advance,
+Evan Rysdam
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1854577 b/results/classifier/deepseek-2-tmp/output/boot/1854577
new file mode 100644
index 000000000..5ffcc5930
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1855002 b/results/classifier/deepseek-2-tmp/output/boot/1855002
new file mode 100644
index 000000000..f0c127b35
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1857143 b/results/classifier/deepseek-2-tmp/output/boot/1857143
new file mode 100644
index 000000000..d9b937aa6
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1859 b/results/classifier/deepseek-2-tmp/output/boot/1859
new file mode 100644
index 000000000..abdc6da1b
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1859106 b/results/classifier/deepseek-2-tmp/output/boot/1859106
new file mode 100644
index 000000000..18c5cf8f3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1859656 b/results/classifier/deepseek-2-tmp/output/boot/1859656
new file mode 100644
index 000000000..ada5e557f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1860914 b/results/classifier/deepseek-2-tmp/output/boot/1860914
new file mode 100644
index 000000000..fada6285e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1870911 b/results/classifier/deepseek-2-tmp/output/boot/1870911
new file mode 100644
index 000000000..5038e64f0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1870911
@@ -0,0 +1,12 @@
+
+QEMU Crashes on Launch, Windows
+
+Hi,
+
+I an having no issues up to (and including) v5.0.0-rc0, but when I move to rc1 ... it won't even execute in Windows. If I just try to, for example, run
+
+qemu-system-x86_64.exe --version
+
+No output, it just exits. This seems to be new with this version.
+
+Thanks!
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1881249 b/results/classifier/deepseek-2-tmp/output/boot/1881249
new file mode 100644
index 000000000..3ec7edb1e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1882671 b/results/classifier/deepseek-2-tmp/output/boot/1882671
new file mode 100644
index 000000000..48dcccc3a
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1892540 b/results/classifier/deepseek-2-tmp/output/boot/1892540
new file mode 100644
index 000000000..249df14b2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1906156 b/results/classifier/deepseek-2-tmp/output/boot/1906156
new file mode 100644
index 000000000..1c1fbef97
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1906156
@@ -0,0 +1,16 @@
+
+Host OS Reboot Required, for Guest kext to Load (Fully)
+
+Hi,
+
+Finding this one a bit odd, but I am loading a driver (kext) in a macOS guest ... and it works, on the first VM (domain) startup after a full / clean host OS boot (or reboot). However, if I even reboot the guest OS, then the driver load fails => can be "corrected" by a full host OS reboot (which seems very extreme).
+
+Is this a known issue, and/or is there a workaround?
+
+FYI, running,
+QEMU emulator version 5.0.0 (Debian 1:5.0-5ubuntu9.1)
+Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
+
+This is for a macOS guest, on a Linux host.
+
+Thanks!
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1906905 b/results/classifier/deepseek-2-tmp/output/boot/1906905
new file mode 100644
index 000000000..93aa78873
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1907953 b/results/classifier/deepseek-2-tmp/output/boot/1907953
new file mode 100644
index 000000000..34297cd70
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1908416 b/results/classifier/deepseek-2-tmp/output/boot/1908416
new file mode 100644
index 000000000..2b210ac2f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1915794 b/results/classifier/deepseek-2-tmp/output/boot/1915794
new file mode 100644
index 000000000..251f6c051
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1923497 b/results/classifier/deepseek-2-tmp/output/boot/1923497
new file mode 100644
index 000000000..4f427def1
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1925417 b/results/classifier/deepseek-2-tmp/output/boot/1925417
new file mode 100644
index 000000000..ee2410b2c
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1926052 b/results/classifier/deepseek-2-tmp/output/boot/1926052
new file mode 100644
index 000000000..203b38b98
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/1962 b/results/classifier/deepseek-2-tmp/output/boot/1962
new file mode 100644
index 000000000..6f1517409
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1962
@@ -0,0 +1,30 @@
+
+systemd-tmpfiles-setup-dev-early.service fails in emulated systemd-nspawn container
+Description of problem:
+When booting a fresh `debootstrap`ed Debian Trixie/testing rootfs with foreign architecture via `systemd-nspawn` and `qemu-user-static`, invoked via `systemd-binfmt`, the `systemd-tmpfiles-setup-dev-early.service` service within the guest fails, which leads to `/dev` not existing (respectively no default content), so that several other guest system components fail as well, like any console/shell access:
+```
+Starting systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully...
+systemd-tmpfiles-setup-dev-early.service: Failed to set up credentials: Invalid argument
+systemd-tmpfiles-setup-dev-early.service: Main process exited, code=exited, status=243/CREDENTIALS
+systemd-tmpfiles-setup-dev-early.service: Failed with result 'exit-code'.
+[FAILED] Failed to start systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully.
+See 'systemctl status systemd-tmpfiles-setup-dev-early.service' for details.
+Starting systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev...
+systemd-tmpfiles-setup-dev.service: Failed to set up credentials: Invalid argument
+systemd-tmpfiles-setup-dev.service: Main process exited, code=exited, status=243/CREDENTIALS
+systemd-tmpfiles-setup-dev.service: Failed with result 'exit-code'.
+[FAILED] Failed to start systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev.
+See 'systemctl status systemd-tmpfiles-setup-dev.service' for details.
+```
+Steps to reproduce:
+1. `apt install debootstrap systemd-container qemu-user-static`
+2. `systemctl restart systemd-binfmt`
+3. `mkdir rootfs`
+4. `debootstrap --variant=minbase --include=systemd-sysv --arch=arm64 trixie ./rootfs 'https://deb.debian.org/debian'`
+5. `systemd-nspawn -bD rootfs`
+Additional information:
+On Bookworm guest systems and/or without QEMU emulation, this works without issues, so I guess systemd recently started to use a certain syscall for the `ImportCredential=tmpfiles.*` method in systemd units, which is not supported by QEMU, probably similar to https://github.com/systemd/systemd/pull/28954?
+
+I hope it is fine to report it here. Always difficult to decide whether to report to the distribution (Debian) or one, and in case which, of the related projects, which do not work together.
+
+Debian Trixie currently ships `systemd 254.4-1` btw. I am not sure whether the issue was introduced with 253 or 254, since the linked issue prevented booting such containers on an earlier stage with 253, which was fixed in 254, which has the here reported issue.
diff --git a/results/classifier/deepseek-2-tmp/output/boot/1995 b/results/classifier/deepseek-2-tmp/output/boot/1995
new file mode 100644
index 000000000..d4298b3ef
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/1995
@@ -0,0 +1,2 @@
+
+No equivalent of `-boot once` for `bootindex`
diff --git a/results/classifier/deepseek-2-tmp/output/boot/206 b/results/classifier/deepseek-2-tmp/output/boot/206
new file mode 100644
index 000000000..42501cf55
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/206
@@ -0,0 +1,2 @@
+
+Dos on the fly CD image replacement is not Working with DOS
diff --git a/results/classifier/deepseek-2-tmp/output/boot/2090 b/results/classifier/deepseek-2-tmp/output/boot/2090
new file mode 100644
index 000000000..65e212078
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/2109 b/results/classifier/deepseek-2-tmp/output/boot/2109
new file mode 100644
index 000000000..9812456be
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/2109
@@ -0,0 +1,2 @@
+
+NetBSD VM fails to install due to missing py311-expat package
diff --git a/results/classifier/deepseek-2-tmp/output/boot/2234 b/results/classifier/deepseek-2-tmp/output/boot/2234
new file mode 100644
index 000000000..6cbbd6245
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/2234
@@ -0,0 +1,24 @@
+
+upon pressing F2 failures in loading the edk2 bios interface app
+Description of problem:
+Cosmetic, low priority, but maybe easy to fix  
+Occasional failures to load the edk2 bios interface app  
+Workaround, retry until success
+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. 
+   This bug concerns the case when it does not work
+
+For reasons not clear, sometimes, after pressing F2, and after qemu registered the key-stroke (F2) and responded by changing the window size, the bios interface loading process seems to abruptly stop at the following guest-display-screen with the following message.  
+```BdsDxe: Loading Boot0000 "UiApp" From Fv(7CB8BDC9-F8EB-F434-AAEA-3EE4AF6516A1)/FvFile(462CAA21-7614-4503-836E-8AB6F4662311)```  
+![QEMU_3_21_2024_12_52_10_PM](/uploads/4f9f9a751eb2496c6c9947b34cf24893/QEMU_3_21_2024_12_52_10_PM.png)
+
+When the bios interface loading process does succeed, it goes to the expected screen:  
+![QEMU_3_21_2024_11_25_00_AM](/uploads/38b4ad718357debc798c3a804954a52d/QEMU_3_21_2024_11_25_00_AM.png)
+Additional information:
+Unsure if this sort of bug should go upstream to https://github.com/tianocore/edk2/issues   
+Herein notifying @kraxel 
+
+Not a measured statistic, but on basis of feeling, I'd qualitatively say 4 out of 5 times it fails to bring up the bios interface. Its a bit frustrating because it feels like one has no control over it and a successful event is left to chance.  
+
+This isn't a recent introduction/regression. I've noticed this since 8.0.0, so its been this way maybe longer.
diff --git a/results/classifier/deepseek-2-tmp/output/boot/2235 b/results/classifier/deepseek-2-tmp/output/boot/2235
new file mode 100644
index 000000000..9cb2e5869
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/2280 b/results/classifier/deepseek-2-tmp/output/boot/2280
new file mode 100644
index 000000000..39b2c5299
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/2280
@@ -0,0 +1,2 @@
+
+Not Installing Properly
diff --git a/results/classifier/deepseek-2-tmp/output/boot/2365 b/results/classifier/deepseek-2-tmp/output/boot/2365
new file mode 100644
index 000000000..bed0f8366
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/2686 b/results/classifier/deepseek-2-tmp/output/boot/2686
new file mode 100644
index 000000000..3c51c91e7
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/2700 b/results/classifier/deepseek-2-tmp/output/boot/2700
new file mode 100644
index 000000000..1e0512f03
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/2840 b/results/classifier/deepseek-2-tmp/output/boot/2840
new file mode 100644
index 000000000..ed83c6068
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/2847 b/results/classifier/deepseek-2-tmp/output/boot/2847
new file mode 100644
index 000000000..20da2f6d2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/2847
@@ -0,0 +1,2 @@
+
+Provide short option for UEFI firmware
diff --git a/results/classifier/deepseek-2-tmp/output/boot/2940 b/results/classifier/deepseek-2-tmp/output/boot/2940
new file mode 100644
index 000000000..322aaaf56
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/2940
@@ -0,0 +1,2 @@
+
+Fix i cant boot nextstep os in qemu m68k using next-cube
diff --git a/results/classifier/deepseek-2-tmp/output/boot/366 b/results/classifier/deepseek-2-tmp/output/boot/366
new file mode 100644
index 000000000..563fc30bc
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/366
@@ -0,0 +1,2 @@
+
+How to make OVMF
diff --git a/results/classifier/deepseek-2-tmp/output/boot/393569 b/results/classifier/deepseek-2-tmp/output/boot/393569
new file mode 100644
index 000000000..b143558b1
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/425 b/results/classifier/deepseek-2-tmp/output/boot/425
new file mode 100644
index 000000000..c4c5fca75
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/436 b/results/classifier/deepseek-2-tmp/output/boot/436
new file mode 100644
index 000000000..c1995e670
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/436
@@ -0,0 +1,2 @@
+
+window 8 stuck during boot on Qemu
diff --git a/results/classifier/deepseek-2-tmp/output/boot/55 b/results/classifier/deepseek-2-tmp/output/boot/55
new file mode 100644
index 000000000..4da947109
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/55
@@ -0,0 +1,2 @@
+
+Can't install Windows 7 with q35 (SATA)
diff --git a/results/classifier/deepseek-2-tmp/output/boot/551545 b/results/classifier/deepseek-2-tmp/output/boot/551545
new file mode 100644
index 000000000..7b2423600
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/586175 b/results/classifier/deepseek-2-tmp/output/boot/586175
new file mode 100644
index 000000000..f7c188f7d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/588735 b/results/classifier/deepseek-2-tmp/output/boot/588735
new file mode 100644
index 000000000..db5831188
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/588735
@@ -0,0 +1,20 @@
+
+Quit command not working
+
+Qemu strace
+
+
+
+rt_sigreturn(0x1b)                      = 56
+clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6fddecbad0) = ? ERESTARTNOINTR (To be restarted)
+--- SIGPROF (Profiling timer expired) @ 0 (0) ---
+rt_sigreturn(0x1b)                      = 56
+
+
+started with :
+
+[root@virtual-test ~]# /root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -chardev socket,id=serial0,host=0.0.0.0,port=$CONSOLEPORT,telnet,server,nowait -serial chardev:serial0 -hda hda -hdb hdb -hdc hdc -hdd hdd -fda fd0 -fdb fd1 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -M pc -m 4096
+
+when removing -m 4096, the quit command works.
+
+but I think its a combination of different args that causes the problem.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/588748 b/results/classifier/deepseek-2-tmp/output/boot/588748
new file mode 100644
index 000000000..55d9b38f3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/598 b/results/classifier/deepseek-2-tmp/output/boot/598
new file mode 100644
index 000000000..27c918c94
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/598
@@ -0,0 +1,2 @@
+
+QEMU boot kernel for ppc e300c3 problem
diff --git a/results/classifier/deepseek-2-tmp/output/boot/599 b/results/classifier/deepseek-2-tmp/output/boot/599
new file mode 100644
index 000000000..db11c3096
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/622367 b/results/classifier/deepseek-2-tmp/output/boot/622367
new file mode 100644
index 000000000..c41c4d629
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/622367
@@ -0,0 +1,9 @@
+
+No BIOS MPFP structure with smp=92 and more
+
+qemu 0.12.2, SeaBios 0.5.1, running qemu-system-x86_64.exe with option -smp.
+If smp>=92 then no MP floating point structure present in 1 Mb. This may be verified by pmemsave 0 0x100000 in debugger and search for _MP_ signature in file.
+
+qemu 0.10.5 (bios build 05/08/09) can smp=128 (and even 255 if not hangs :).
+
+Host win 7 x64 RTM 7600.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/623852 b/results/classifier/deepseek-2-tmp/output/boot/623852
new file mode 100644
index 000000000..d8c2cdd0e
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/623852
@@ -0,0 +1,14 @@
+
+PPC emulation loops on booting a FreeBSD kernel
+
+Has anyone tried booting FreeBSD8.1-ppc under QEMU (Linux x86_64 host; PPC guest)?  I can get Linux/PPC to run fine, and FreeBSD8.1-i386 as well; but there seems to be a problem with whatever the FreeBSD8.1 kernel does, that QEMU's PPC emulation can't handle.
+
+I am using the latest version of QEMU from GIT as of 25/8/10.  I don't know how to get a "git commit hash", so I can't quote it.
+
+The kernel starts OK then loops after "Kernel entry at 0x100100 ...".
+
+The command I am running is
+
+qemu-system-ppc -cdrom FreeBSD-8.1-RELEASE-powerpc-disc1.iso -hda freebsd8.1-ppc -m 94 -boot d"
+
+I obtained the kernel from ftp://ftp.freebsd.org/pub/FreeBSD/releases/powerpc/ISO-IMAGES/8.1/FreeBSD-8.1-RELEASE-powerpc-disc1.iso.
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/627982 b/results/classifier/deepseek-2-tmp/output/boot/627982
new file mode 100644
index 000000000..76a969b82
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/627982
@@ -0,0 +1,8 @@
+
+linux 2.6.35 hangs with -no-acpi
+
+Linux 2.6.35 hangs at boot when giving -no-acpi to qemu, for instance the Debian kernel:
+
+qemu -no-acpi -kernel /boot/vmlinuz-2.6.35-trunk-686 
+
+There is no output except just "Booting the kernel"
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/639651 b/results/classifier/deepseek-2-tmp/output/boot/639651
new file mode 100644
index 000000000..3a8d539de
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/639651
@@ -0,0 +1,22 @@
+
+DRIVER_IRQL_NOT_LESS_OR_EQUAL booting WIndows XP with Synaptics driver installed
+
+Positng the issue here since I did not get any reply on the ML.
+
+I was trying to update some windows XP (SP3) images in kvm.
+
+It worked fine several times but last time I added mass storage
+drivers to sysprep and now on the second boot after reseal (the first
+is mini-setup) I get a BSOD with message
+DRIVER_IRQL_NOT_LESS_OR_EQUAL. I can post the screenshot if somebody
+thinks it is interesting enough.
+
+The same image works on hardware (which has controllers different from
+the qemu PIIX3) and in VirtualBox (with the default PIIX4 as well as
+PIIX3) so long as IO apic is enabled).
+
+I am not sure if this is an error with the MS drivers or how they are
+used in sysprep in this particular case or if his is some strange
+error in qemu emulation in the PIIX3 controller or elsewhere.
+
+The image is originally created on hardware with MP acpi (not virtualization).
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/670 b/results/classifier/deepseek-2-tmp/output/boot/670
new file mode 100644
index 000000000..f875dcbce
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/697 b/results/classifier/deepseek-2-tmp/output/boot/697
new file mode 100644
index 000000000..dfa83e892
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/697
@@ -0,0 +1,2 @@
+
+linux-user create default CPU type before parsing the ELF header for specific CPU type
diff --git a/results/classifier/deepseek-2-tmp/output/boot/723460 b/results/classifier/deepseek-2-tmp/output/boot/723460
new file mode 100644
index 000000000..63c30c48d
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/760956 b/results/classifier/deepseek-2-tmp/output/boot/760956
new file mode 100644
index 000000000..e205faf0f
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/818647 b/results/classifier/deepseek-2-tmp/output/boot/818647
new file mode 100644
index 000000000..7e787b5f3
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/825776 b/results/classifier/deepseek-2-tmp/output/boot/825776
new file mode 100644
index 000000000..05e3d6256
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/825776
@@ -0,0 +1,15 @@
+
+-boot -hda //.//physicaldrivex does not work if it is USB drive
+
+qemu-system-x86_64.exe -L . -name "RMPrepUSB Emulation Session" -boot c -m 500 -hda //./PhysicalDrive1
+
+just opens a blank QEMU window (no BIOS POSt messages) and does nothing
+
+qemu v 0.15.0
+Under Windows 7 64-bit
+drive1 is a USB Flash drive
+
+Previous version of x86_64 (Jan 2010) works fine. If replace with new version (or RC2 version) then does not work.
+
+if use harddisk.img raw file instead of USB physical device then I get BIOS POST messages and it boots to image OK.
+So appears to be USB or physicaldisk support issue???
\ No newline at end of file
diff --git a/results/classifier/deepseek-2-tmp/output/boot/830833 b/results/classifier/deepseek-2-tmp/output/boot/830833
new file mode 100644
index 000000000..84180d2f4
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/833658 b/results/classifier/deepseek-2-tmp/output/boot/833658
new file mode 100644
index 000000000..2c53de0b2
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/966316 b/results/classifier/deepseek-2-tmp/output/boot/966316
new file mode 100644
index 000000000..4a5365d60
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/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/deepseek-2-tmp/output/boot/994 b/results/classifier/deepseek-2-tmp/output/boot/994
new file mode 100644
index 000000000..9bdedccc0
--- /dev/null
+++ b/results/classifier/deepseek-2-tmp/output/boot/994
@@ -0,0 +1,6 @@
+
+7.0.0-rc4 doesn't launch on Windows
+Description of problem:
+The program immediately exits, without even printing version information (or anything).
+Steps to reproduce:
+1. Run the command above