diff options
Diffstat (limited to 'results/classifier/deepseek-2/output/boot')
189 files changed, 3636 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2/output/boot/1012023 b/results/classifier/deepseek-2/output/boot/1012023 new file mode 100644 index 000000000..a1fa043e6 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1013888 b/results/classifier/deepseek-2/output/boot/1013888 new file mode 100644 index 000000000..4b6247ac4 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1042084 b/results/classifier/deepseek-2/output/boot/1042084 new file mode 100644 index 000000000..a610a1774 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1054 b/results/classifier/deepseek-2/output/boot/1054 new file mode 100644 index 000000000..b0e193833 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1054 @@ -0,0 +1,31 @@ + +Unable to start CirrOS 0.5.1 on QEMU 7.0 with -M virt and -cpu max +Description of problem: + +Steps to reproduce: +1. Fetch CirrOS image: ```wget https://github.com/cirros-dev/cirros/releases/download/0.5.1/cirros-0.5.1-aarch64-disk.img``` +2. Run QEMU: + ``` + qemu-system-aarch64 -drive file=cirros-0.5.1-aarch64-disk.img -M virt -m 2048 \ + -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd -cpu max -nographic + ``` +Additional information: +When image boots, GRUB window appears for a second and then kernel/initramfs are loaded and booted: +``` +EFI stub: Booting Linux Kernel... +EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied +EFI stub: Using DTB from configuration table +EFI stub: Exiting boot services and installing virtual address map... +``` + +When everything is fine we can see kernel output: +``` +[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd070] +[ 0.000000] Linux version 5.3.0-26-generic (buildd@bos02-arm64-028) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #28~18.04.1-Ubuntu SMP Wed Dec 18 16:41:01 UTC 2019 (Ubuntu 5.3.0-26.28~18.04.1-generic 5.3.13) +[ 0.000000] efi: Getting EFI parameters from FDT: +[ 0.000000] efi: EFI v2.70 by EDK II +``` + +But on QEMU 7.0 with ```-M virt -cpu max``` we never get kernel output. + +# diff --git a/results/classifier/deepseek-2/output/boot/1063 b/results/classifier/deepseek-2/output/boot/1063 new file mode 100644 index 000000000..e99fe5c9c --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1063 @@ -0,0 +1,10 @@ + +qemu: could not load PC BIOS 'bios-256k.bin' +Description of problem: +I cloned latest QEMU and build in Ubuntu 18.04, when I run QEMU to start a vm, it tells me `could not load PC BIOS 'bios-256k.bin' + + +Steps to reproduce: +1. Clone latest QEMU in Ubuntu18.04 +2. build QEMU +3. Use QEMU and libvirt to start a virtual machine. diff --git a/results/classifier/deepseek-2/output/boot/1077806 b/results/classifier/deepseek-2/output/boot/1077806 new file mode 100644 index 000000000..44ce0d20f --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1115 b/results/classifier/deepseek-2/output/boot/1115 new file mode 100644 index 000000000..3fc8299fd --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1115 @@ -0,0 +1,15 @@ + +qemu 7.0.0 stuck at Windows boot logo with SeaBios and MBR disk +Description of problem: +When trying to boot an MBR Windows guest with SeaBios, it is stuck at the blue Windows boot logo, before the loading circle. +Changing the vGPU doesn't help, 0% cpu load just frozen. Even if I boot a WinPE iso, the same happens. +Even after 30 minutes, the same. +Rebooted host multiple times. +Since SeaBios is the default in qemu and virt-manager I imagine many VMs are installed as MBR and thus will be stuck. +To boot the VM I have to: +- switch to UEFI (TianoCore) +- boot WinPE iso +- use proprietary software to convert the Windows disk from MBR to GPT +Then it boots just fine but I imagine not many users will be able to do this. +Steps to reproduce: +1. boot Windows image / WinPE iso with SeaBios diff --git a/results/classifier/deepseek-2/output/boot/1120 b/results/classifier/deepseek-2/output/boot/1120 new file mode 100644 index 000000000..a0b9e195a --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1122492 b/results/classifier/deepseek-2/output/boot/1122492 new file mode 100644 index 000000000..ff8af3c84 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1131757 b/results/classifier/deepseek-2/output/boot/1131757 new file mode 100644 index 000000000..9ea4082bc --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1135 b/results/classifier/deepseek-2/output/boot/1135 new file mode 100644 index 000000000..1135ea608 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1135 @@ -0,0 +1,13 @@ + +Multiboot: invalid multiboot information block +Description of problem: +Breakpoint at 0x85d4, this is the entrypoint of this Multiboot loader. +According to the Multiboot specification, the EAX register should be a pointer to the Multiboot information block. When I am testing, it is 0x9500. However, when dumping the memory using `dump binary memory`, nearby memory areas are all zeros. + +When dumping some bigger memory aeras, I found that the module hasbeen loaded to the memory successfully, altough MBI was broken. +Steps to reproduce: + +Additional information: +multiboot: [multiboot](/uploads/55fdfcf30ada0af2d00badf11fcd308c/multiboot) + +toop: [toop](/uploads/de3b63ae021303c544105ba1498f3373/toop) diff --git a/results/classifier/deepseek-2/output/boot/1160 b/results/classifier/deepseek-2/output/boot/1160 new file mode 100644 index 000000000..8f9cc12a1 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1160 @@ -0,0 +1,2 @@ + +hw/riscv reset vector improvement diff --git a/results/classifier/deepseek-2/output/boot/1177 b/results/classifier/deepseek-2/output/boot/1177 new file mode 100644 index 000000000..8663b2c39 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1177 @@ -0,0 +1,17 @@ + +booting linux hangs with -cpu max or -cpu max,lpa2=off, but works with -cpu cortex-a57 +Description of problem: + +Steps to reproduce: +1. Snag mini.iso from http://ports.ubuntu.com/ubuntu-ports/dists/bionic-updates/main/installer-arm64/current/images/netboot/mini.iso +2. qemu-img create ubuntu-image.img 20G +3. dd if=/dev/zero of=flash1.img bs=1M count=64 +4. dd if=/dev/zero of=flash0.img bs=1M count=64 +5. dd if=/home/imp/git/qemu/00-build/pc-bios/edk2-aarch64-code.fd of=flash0.img conv=notrunc +6. Run the above command +7. Select install, watch the kernel hang. +8. Change -cpu max to -cpu cortex-a57 and it will work. -cpu max,lpa2=off also exhibits the problem +Additional information: +Just grabbed git and built it with ./configure in /home/imp/git/qemu/00-build. + +pm215 on irc suggested that it was an old EDK2 and a newer one is needed to cope with the newer CPU features in -cpu max diff --git a/results/classifier/deepseek-2/output/boot/1246 b/results/classifier/deepseek-2/output/boot/1246 new file mode 100644 index 000000000..cde3cfcf3 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1246 @@ -0,0 +1,2 @@ + +Win11_22H2_English_x64.iso won't boot diff --git a/results/classifier/deepseek-2/output/boot/1252 b/results/classifier/deepseek-2/output/boot/1252 new file mode 100644 index 000000000..394ef8be8 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1252 @@ -0,0 +1,18 @@ + +Debian Raspberry Pi images do not boot with version 7 and higher +Description of problem: +The Debian Bullseye RPi4 4GB image [here](https://raspi.debian.net/tested-images/) does not boot with versions 7 and higher, while it does boot with v6.2.0. The Bookworm image works with v7. +Steps to reproduce: +0. `export DEB_VERS=5.10.0-11` +1. `wget https://raspi.debian.net/tested/20220121_raspi_4_bullseye.img.xz` +2. `dd if=/dev/null of=disk-$DEB_VERS.img bs=1M seek=10240` + * NB: This creates a 10 GB file +3. `xzcat $RPI_IMG | dd of=disk-$DEB_VERS.img conv=notrunc status=progress` +4. `partx -a -v disk-$DEB_VERS.img` +5. `mount /dev/loop0p1 /mnt` +6. `cp /mnt/initrd.img-$DEB_VERS-arm64 .` +7. `cp /mnt/vmlinuz-$DEB_VERS-arm64 .` +8. `umount /mnt` +9. `qemu-system-aarch64 -M virt -m 4096 -cpu max -drive format=raw,file=disk-$DEB_VERS.img -nographic -append "console=tty0 console=ttyAMA0,115200 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=64M rootwait" -initrd initrd.img-$DEB_VERS-arm64 -kernel vmlinuz-$DEB_VERS-arm64` +Additional information: +The URL for the image in step 1 has been known to change, so if you get a 404, go to the URL above and find the correct one. diff --git a/results/classifier/deepseek-2/output/boot/1260555 b/results/classifier/deepseek-2/output/boot/1260555 new file mode 100644 index 000000000..41be0c80e --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1268279 b/results/classifier/deepseek-2/output/boot/1268279 new file mode 100644 index 000000000..5c1e8e1b3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1269 b/results/classifier/deepseek-2/output/boot/1269 new file mode 100644 index 000000000..ddf9e1d76 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1269 @@ -0,0 +1,27 @@ + +qemu-system-i386 no longer boots NetBSD +Description of problem: +Since qemu commit e3a79e0e87831602e41819591a8e6dcc70a2a231, NetBSD +no longer boots under qemu-system-i386. +Steps to reproduce: +1. `wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.2/i386/installation/cdrom/boot-com.iso` +2. `qemu-system-i386 -nographic -cdrom boot-com.iso` + +Expected behavior: the system boots and prompts you for a terminal type with + + Terminal type (just hit ENTER for 'vt220'): + +Observed incorrect behavior: the guest kernel either hangs during boot at + + Loading /stand/i386/9.2/modules/cd9660/cd9660.kmod + WARNING: 1 module failed to load + +or panics during boot with + + kernel: supervisor trap page fault, code=0 + Stopped in pid 0.1 (system) at netbsd:idt_vec_reserve+0xa: cmpb $0,netbs + d:idt_allocmap(%ebx) + db{0}> +Additional information: +This regression is a critical issue to the NetBSD project as its automated +testing infrastructure is heavily dependent on qemu-system-i386. diff --git a/results/classifier/deepseek-2/output/boot/1273944 b/results/classifier/deepseek-2/output/boot/1273944 new file mode 100644 index 000000000..b602f48e3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1280 b/results/classifier/deepseek-2/output/boot/1280 new file mode 100644 index 000000000..8a5b9c873 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1280 @@ -0,0 +1,9 @@ + +qemu-system-arm 7.1 can not boot my cortex-m55 image +Steps to reproduce: +``` +1.qemu-system-arm -cpu cortex-m55 -machine mps3-an547 -nographic -vga none -monitor none -semihosting -semihosting-config enable=on,target=native -kernel qemu_simu.elf +2.arm-none-eabi-gdb -ex "target extended-remote localhost:1234" qemu_simu.elf +``` +Additional information: +[qemu_simu.tar.gz](/uploads/b8b3bf0f4868fdbb22b19027f685b4f0/qemu_simu.tar.gz) diff --git a/results/classifier/deepseek-2/output/boot/1293 b/results/classifier/deepseek-2/output/boot/1293 new file mode 100644 index 000000000..33c5b09b9 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1293 @@ -0,0 +1,2 @@ + +Trusted Firmware stopped booting on SBSA-ref diff --git a/results/classifier/deepseek-2/output/boot/1314667 b/results/classifier/deepseek-2/output/boot/1314667 new file mode 100644 index 000000000..5305b75ca --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1320 b/results/classifier/deepseek-2/output/boot/1320 new file mode 100644 index 000000000..c66fdf89f --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1320 @@ -0,0 +1,13 @@ + +qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin" +Description of problem: +qemu-system-riscv64: Unable to load the RISC-V firmware "opensbi-riscv64-virt-fw_jump.bin" +Steps to reproduce: +1. wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.79.tar.xz +2. sudo apt-get install crossbuild-essential-riscv64 +3. make ARCH=riscv defconfig && make ARCH=riscv menuconfig +4. make -j4 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- +5. trucate -s 128G rootfs.img && mkfs.ext4 rootfs.img +6. sudo mount -o loop ./rootfs.img /mnt +7. debootstrap --arch=riscv64 focal /mnt +8. qemu-system-riscv64 -machine virt -bios default -m 512M -kernel ./linux-5.15.79/arch/riscv/boot/Image -drive file=./rootfs.img,format=raw diff --git a/results/classifier/deepseek-2/output/boot/1328 b/results/classifier/deepseek-2/output/boot/1328 new file mode 100644 index 000000000..c91ed2cf5 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1328 @@ -0,0 +1,10 @@ + +Cannot boot any UEFI systems after upgrade edk2-ovmf +Description of problem: +After upgrading edk2-ovmf from version 202208-1 to version 202208-3 none of my virtual machines on UEFI (windows and Arch linuw guest) have successfully started. + +I'm using Virtual Manager and virt-viewer with virsh. +Steps to reproduce: +1. Update edk2-ovmf to 202208-3 +2. Restart all running VM +3. Vm with UEFI bios cannot boot diff --git a/results/classifier/deepseek-2/output/boot/1331859 b/results/classifier/deepseek-2/output/boot/1331859 new file mode 100644 index 000000000..9e487786a --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1358722 b/results/classifier/deepseek-2/output/boot/1358722 new file mode 100644 index 000000000..32727f567 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1363467 b/results/classifier/deepseek-2/output/boot/1363467 new file mode 100644 index 000000000..c2cdb0284 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1435101 b/results/classifier/deepseek-2/output/boot/1435101 new file mode 100644 index 000000000..ea0ed9af3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1437 b/results/classifier/deepseek-2/output/boot/1437 new file mode 100644 index 000000000..a82cb8952 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1437 @@ -0,0 +1,7 @@ + +Nitrux doesn't finish boot process +Description of problem: +Boot process doesn't finish + +Steps to reproduce: +1.Load Nitrux ISO diff --git a/results/classifier/deepseek-2/output/boot/1447 b/results/classifier/deepseek-2/output/boot/1447 new file mode 100644 index 000000000..11a1d1140 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1447 @@ -0,0 +1,8 @@ + +riscv: reset_vec uses CSR even when disabled causing inability to boot +Steps to reproduce: +1. Run any rv32 binary with `./qemu-system-riscv32 -cpu rv32,d=off,f=off,Zicsr=off` + +To view using GDB use `./qemu-system-riscv32 -cpu rv32,d=off,f=off,Zicsr=off -S -s` +`gdb-multiarch --ex="target remote localhost:1234" -ex "layout asm"` +then type `si` till $pc jumps to zero on `csrr a0, mhartid` diff --git a/results/classifier/deepseek-2/output/boot/1473451 b/results/classifier/deepseek-2/output/boot/1473451 new file mode 100644 index 000000000..4c2be2ae8 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1476800 b/results/classifier/deepseek-2/output/boot/1476800 new file mode 100644 index 000000000..8c4a3e6ba --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1496712 b/results/classifier/deepseek-2/output/boot/1496712 new file mode 100644 index 000000000..b6d9f20b8 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1512134 b/results/classifier/deepseek-2/output/boot/1512134 new file mode 100644 index 000000000..b2db69a1f --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1551 b/results/classifier/deepseek-2/output/boot/1551 new file mode 100644 index 000000000..8bf7fea21 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1551 @@ -0,0 +1,41 @@ + +qemu-system-arm: ../accel/tcg/cpu-exec.c:917: cpu_loop_exec_tb: Assertion `icount_enabled()' failed. +Description of problem: +When starting the guest, the mentioned assertion is triggered very soon: +``` +qemu-system-arm: ../accel/tcg/cpu-exec.c:917: cpu_loop_exec_tb: Assertion `icount_enabled()' failed. +``` +I'm able to successfully boot the same image with QEMU 7.2.0. + +The last output from the qemu logging with `-d guest_errors,in_asm,int,pcall,cpu` is +``` +---------------- +IN: +0x40209100: e92d4ff0 push {r4, r5, r6, r7, r8, sb, sl, fp, lr} +0x40209104: e28db020 add fp, sp, #0x20 +0x40209108: e24b3f49 sub r3, fp, #0x124 +0x4020910c: e24ddf43 sub sp, sp, #0x10c +0x40209110: e1a0e00f mov lr, pc +0x40209114: e3e0f0ff mvn pc, #0xff + +R00=4021000c R01=4020a5f8 R02=0000000f R03=40209100 +R04=40210018 R05=40210018 R06=4020c000 R07=40002000 +R08=00000000 R09=00000000 R10=00000000 R11=4020d7fc +R12=00000000 R13=4020d7f0 R14=4020074c R15=40209100 +PSR=2000011f --C- A sys32 +---------------- +IN: +0xffffff00: ee1d0f50 mrc p15, #0, r0, c13, c0, #2 + +R00=4021000c R01=4020a5f8 R02=0000000f R03=4020d6c8 +R04=40210018 R05=40210018 R06=4020c000 R07=40002000 +R08=00000000 R09=00000000 R10=00000000 R11=4020d7ec +R12=00000000 R13=4020d6c0 R14=40209118 R15=ffffff00 +PSR=2000011f --C- A sys32 +``` + +Please note that the L4Re OS uses `mvn pc, #0xff` to switch from EL1 to EL2 (system call). +Steps to reproduce: +1. Boot the attached image with the provided command line to trigger the assertion +Additional information: +I will attach the bootstrap image to this ticket. diff --git a/results/classifier/deepseek-2/output/boot/1586229 b/results/classifier/deepseek-2/output/boot/1586229 new file mode 100644 index 000000000..42bfb0dc2 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1589 b/results/classifier/deepseek-2/output/boot/1589 new file mode 100644 index 000000000..703a8996b --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1589257 b/results/classifier/deepseek-2/output/boot/1589257 new file mode 100644 index 000000000..dc536a4e6 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1590796 b/results/classifier/deepseek-2/output/boot/1590796 new file mode 100644 index 000000000..2ff87d715 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1598029 b/results/classifier/deepseek-2/output/boot/1598029 new file mode 100644 index 000000000..69de96b10 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1599214 b/results/classifier/deepseek-2/output/boot/1599214 new file mode 100644 index 000000000..b0dcc9d0f --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1614348 b/results/classifier/deepseek-2/output/boot/1614348 new file mode 100644 index 000000000..611d620b3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1629282 b/results/classifier/deepseek-2/output/boot/1629282 new file mode 100644 index 000000000..eba3c337e --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1638 b/results/classifier/deepseek-2/output/boot/1638 new file mode 100644 index 000000000..e4bc7afbd --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1639394 b/results/classifier/deepseek-2/output/boot/1639394 new file mode 100644 index 000000000..7546f3d17 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1653063 b/results/classifier/deepseek-2/output/boot/1653063 new file mode 100644 index 000000000..d32909489 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1695286 b/results/classifier/deepseek-2/output/boot/1695286 new file mode 100644 index 000000000..848d18d0e --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1698574 b/results/classifier/deepseek-2/output/boot/1698574 new file mode 100644 index 000000000..ab47936d3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1701 b/results/classifier/deepseek-2/output/boot/1701 new file mode 100644 index 000000000..e486edebe --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1701 @@ -0,0 +1,6 @@ + +-boot menu=on that vm is hangs +Description of problem: +virtual machine hangs, stop at press ESC for boot menu. +Additional information: + diff --git a/results/classifier/deepseek-2/output/boot/1716510 b/results/classifier/deepseek-2/output/boot/1716510 new file mode 100644 index 000000000..357410c46 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1717708 b/results/classifier/deepseek-2/output/boot/1717708 new file mode 100644 index 000000000..a2affd37f --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1723927 b/results/classifier/deepseek-2/output/boot/1723927 new file mode 100644 index 000000000..0e4d7debf --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1732679 b/results/classifier/deepseek-2/output/boot/1732679 new file mode 100644 index 000000000..9db8dcf17 --- /dev/null +++ b/results/classifier/deepseek-2/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 + \ No newline at end of file diff --git a/results/classifier/deepseek-2/output/boot/1735653 b/results/classifier/deepseek-2/output/boot/1735653 new file mode 100644 index 000000000..fe7fc2853 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1737194 b/results/classifier/deepseek-2/output/boot/1737194 new file mode 100644 index 000000000..5e2c44e76 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1737882 b/results/classifier/deepseek-2/output/boot/1737882 new file mode 100644 index 000000000..cd285cf38 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1737883 b/results/classifier/deepseek-2/output/boot/1737883 new file mode 100644 index 000000000..771739e85 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1743441 b/results/classifier/deepseek-2/output/boot/1743441 new file mode 100644 index 000000000..18fde92cc --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1756080 b/results/classifier/deepseek-2/output/boot/1756080 new file mode 100644 index 000000000..822a072c0 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1776486 b/results/classifier/deepseek-2/output/boot/1776486 new file mode 100644 index 000000000..9859378ce --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1781463 b/results/classifier/deepseek-2/output/boot/1781463 new file mode 100644 index 000000000..66ef2d6a2 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1801 b/results/classifier/deepseek-2/output/boot/1801 new file mode 100644 index 000000000..17b0657be --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1804961 b/results/classifier/deepseek-2/output/boot/1804961 new file mode 100644 index 000000000..eb26fd4e6 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1810956 b/results/classifier/deepseek-2/output/boot/1810956 new file mode 100644 index 000000000..5f952f240 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1811782 b/results/classifier/deepseek-2/output/boot/1811782 new file mode 100644 index 000000000..046f54914 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1811888 b/results/classifier/deepseek-2/output/boot/1811888 new file mode 100644 index 000000000..efb9104da --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1814343 b/results/classifier/deepseek-2/output/boot/1814343 new file mode 100644 index 000000000..16e8f1575 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1815371 b/results/classifier/deepseek-2/output/boot/1815371 new file mode 100644 index 000000000..322ff865e --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1819289 b/results/classifier/deepseek-2/output/boot/1819289 new file mode 100644 index 000000000..43909d2be --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1823152 b/results/classifier/deepseek-2/output/boot/1823152 new file mode 100644 index 000000000..3acae5857 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1823998 b/results/classifier/deepseek-2/output/boot/1823998 new file mode 100644 index 000000000..d3876d114 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1825207 b/results/classifier/deepseek-2/output/boot/1825207 new file mode 100644 index 000000000..2e54b96c2 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1829576 b/results/classifier/deepseek-2/output/boot/1829576 new file mode 100644 index 000000000..1c7ec73f3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1831477 b/results/classifier/deepseek-2/output/boot/1831477 new file mode 100644 index 000000000..285a31962 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1836136 b/results/classifier/deepseek-2/output/boot/1836136 new file mode 100644 index 000000000..5c9080ad7 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1837347 b/results/classifier/deepseek-2/output/boot/1837347 new file mode 100644 index 000000000..37e9aadd0 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1840719 b/results/classifier/deepseek-2/output/boot/1840719 new file mode 100644 index 000000000..3e6477503 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1844635 b/results/classifier/deepseek-2/output/boot/1844635 new file mode 100644 index 000000000..d5e9f9718 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1849234 b/results/classifier/deepseek-2/output/boot/1849234 new file mode 100644 index 000000000..36b787731 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1852196 b/results/classifier/deepseek-2/output/boot/1852196 new file mode 100644 index 000000000..19d805c1e --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1853083 b/results/classifier/deepseek-2/output/boot/1853083 new file mode 100644 index 000000000..dc1a6fd62 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1853781 b/results/classifier/deepseek-2/output/boot/1853781 new file mode 100644 index 000000000..4014069f1 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1854577 b/results/classifier/deepseek-2/output/boot/1854577 new file mode 100644 index 000000000..5ffcc5930 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1855002 b/results/classifier/deepseek-2/output/boot/1855002 new file mode 100644 index 000000000..f0c127b35 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1857143 b/results/classifier/deepseek-2/output/boot/1857143 new file mode 100644 index 000000000..d9b937aa6 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1859 b/results/classifier/deepseek-2/output/boot/1859 new file mode 100644 index 000000000..abdc6da1b --- /dev/null +++ b/results/classifier/deepseek-2/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: + diff --git a/results/classifier/deepseek-2/output/boot/1859106 b/results/classifier/deepseek-2/output/boot/1859106 new file mode 100644 index 000000000..18c5cf8f3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1859656 b/results/classifier/deepseek-2/output/boot/1859656 new file mode 100644 index 000000000..ada5e557f --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1860914 b/results/classifier/deepseek-2/output/boot/1860914 new file mode 100644 index 000000000..fada6285e --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/187 b/results/classifier/deepseek-2/output/boot/187 new file mode 100644 index 000000000..3a76e5f12 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/187 @@ -0,0 +1,2 @@ + +Cannot boot arm kernel images on s390x diff --git a/results/classifier/deepseek-2/output/boot/1870911 b/results/classifier/deepseek-2/output/boot/1870911 new file mode 100644 index 000000000..5038e64f0 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1881249 b/results/classifier/deepseek-2/output/boot/1881249 new file mode 100644 index 000000000..3ec7edb1e --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1882671 b/results/classifier/deepseek-2/output/boot/1882671 new file mode 100644 index 000000000..48dcccc3a --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1892540 b/results/classifier/deepseek-2/output/boot/1892540 new file mode 100644 index 000000000..249df14b2 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1899 b/results/classifier/deepseek-2/output/boot/1899 new file mode 100644 index 000000000..fe620c968 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1899 @@ -0,0 +1,42 @@ + +AArch64: Wrong SCR_EL3 after turning on secondary cores via PSCI +Description of problem: +The system fails to boot when using "direct kernel boot" with EL3 enabled. After the guest OS enables secondary cores via PSCI, those have an incorrectly set up `SCR_EL3`. When the OS then executes an intruction which traps into (QEMU provided fake) EL3, the core ends up in an endless loop of "Undefined Instruction" exceptions. + +This is nicely visible with `-serial stdio -append "earlycon=pl011,0x9000000 console=/dev/ttyAMA0" -d int`: + +```plaintext +[ 0.173173][ T1] smp: Bringing up secondary CPUs ... +(...) +Taking exception 11 [Hypervisor Call] on CPU 0 +...from EL1 to EL2 +...with ESR 0x16/0x5a000000 +...handled as PSCI call +Taking exception 5 [IRQ] on CPU 0 +...from EL1 to EL1 +...with ESR 0x16/0x5a000000 +...with ELR 0xffffa9ff8b593438 +...to EL1 PC 0xffffa9ff8aa11280 PSTATE 0x3c5 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0xffffa9ff8b593438 +Exception return from AArch64 EL1 to AArch64 EL1 PC 0x41f7832c +Taking exception 1 [Undefined Instruction] on CPU 1 +...from EL1 to EL3 +...with ESR 0x18/0x62300882 +...with ELR 0xffffa9ff8aa3d0d8 +...to EL3 PC 0x400 PSTATE 0x3cd +Taking exception 1 [Undefined Instruction] on CPU 1 +...from EL3 to EL3 +...with ESR 0x0/0x2000000 +...with ELR 0x400 +...to EL3 PC 0x200 PSTATE 0x3cd +(repeats forever, CPU 1 is stuck) +``` +Steps to reproduce: +1. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 1 -kernel linux` works +2. `qemu-system-aarch64 -M virt,secure=on -cpu max -smp 2 -kernel linux` does not +Additional information: +The setup for `SCR_EL3` is done by `do_cpu_reset` in hw/arm/boot.c, but this is only called on full system reset. The PSCI call ends up in `arm_set_cpu_on_async_work` (target/arm/arm-powerctl.c) which calls `cpu_reset`. This clears `SCR_EL3` to the architectural reset value, not the one needed for direct kernel boot. + +`arm_set_cpu_on_async_work` has code for `SCR_HCE`, but none of the other flags handled by `do_cpu_reset`. It would probably work after copying all of `do_cpu_reset` into `arm_set_cpu_on_async_work`, but that seems wrong. I prepared a patch which makes `do_cpu_reset` public such that `arm_set_cpu_on_async_work` can call it (works here), but I'm not sure whether that's the right way. + +CC @pm215 diff --git a/results/classifier/deepseek-2/output/boot/1906156 b/results/classifier/deepseek-2/output/boot/1906156 new file mode 100644 index 000000000..1c1fbef97 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1906905 b/results/classifier/deepseek-2/output/boot/1906905 new file mode 100644 index 000000000..93aa78873 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1907953 b/results/classifier/deepseek-2/output/boot/1907953 new file mode 100644 index 000000000..34297cd70 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1908416 b/results/classifier/deepseek-2/output/boot/1908416 new file mode 100644 index 000000000..2b210ac2f --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1915794 b/results/classifier/deepseek-2/output/boot/1915794 new file mode 100644 index 000000000..251f6c051 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1919 b/results/classifier/deepseek-2/output/boot/1919 new file mode 100644 index 000000000..ee1b5c7a9 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1919 @@ -0,0 +1,21 @@ + +UEFI SecureCode hangs on MacOs - 8.1.1 / MacOS Ventura +Description of problem: +Unable to load edk2 secure boot UEFI code. Non-secure edk2 bios works fine, but secure one hangs during load. +Steps to reproduce: +1. Run mentioned command - it should display OVMF logo - but it hangs +Additional information: +* edk2-x86_64-code.fd works fine, edk2-x86_64-secure-code.fd not +* Tested with swtpm and without - doesn't matter +* TPM access has been observed (when swtpm enabled) - sounds like secure-code validation partially works + +To enable TPM: +``` + -chardev socket,id=chrtpm,path=mytpm0/swtpm-sock \ + -tpmdev emulator,id=tpm0,chardev=chrtpm \ + -device tpm-tis,tpmdev=tpm0 \ +``` +and run swtpm +``` +swtpm socket --tpm2 --tpmstate dir=mytpm0 --ctrl type=unixio,path=mytpm0/swtpm-sock +``` diff --git a/results/classifier/deepseek-2/output/boot/192 b/results/classifier/deepseek-2/output/boot/192 new file mode 100644 index 000000000..498af7490 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/192 @@ -0,0 +1,2 @@ + +xv6 Bootloop diff --git a/results/classifier/deepseek-2/output/boot/1923497 b/results/classifier/deepseek-2/output/boot/1923497 new file mode 100644 index 000000000..4f427def1 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1925417 b/results/classifier/deepseek-2/output/boot/1925417 new file mode 100644 index 000000000..ee2410b2c --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1926052 b/results/classifier/deepseek-2/output/boot/1926052 new file mode 100644 index 000000000..203b38b98 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1962 b/results/classifier/deepseek-2/output/boot/1962 new file mode 100644 index 000000000..6f1517409 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/1966 b/results/classifier/deepseek-2/output/boot/1966 new file mode 100644 index 000000000..7eabf0869 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1966 @@ -0,0 +1,9 @@ + +windows xp - some VM's hangs some working (regression?) +Description of problem: +Some of my XP instances behaves strange - seems that explorer.exe is unresponsive for about half an hour after start then works +- normally. +what is worse - there are instance which behaves normally - ie. after launch everything works as expected. +Steps to reproduce: +I want to know. +Additional information: +under qemu 8.0.4 all vms works. diff --git a/results/classifier/deepseek-2/output/boot/1995 b/results/classifier/deepseek-2/output/boot/1995 new file mode 100644 index 000000000..d4298b3ef --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/1995 @@ -0,0 +1,2 @@ + +No equivalent of `-boot once` for `bootindex` diff --git a/results/classifier/deepseek-2/output/boot/2015 b/results/classifier/deepseek-2/output/boot/2015 new file mode 100644 index 000000000..0799a50c1 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2015 @@ -0,0 +1,28 @@ + +qemu-system-sparc fails to boot Solaris 8 in an emulated SS-5 +Description of problem: +Sun PROM fails to boot Solaris 8 in an emulated Sparcstation 5, with qemu exiting with a `trap 0x29` error. +Steps to reproduce: +1. Launch qemu with command line above +2. Sun PROM tries to boot from the network and shows `Tiemout waiting for ARP/RARP packet` messages +3. Interrupt network boot entering `sendkey stop-a` in qemu monitor (`compat_monitor0`) +4. Back in Sun PROM, boot from cdrom: `boot cdrom:d` +5. Solaris 8 starts booting +6. qemu exits with fatal error + +```plaintext +qemu: fatal: Trap 0x29 (Data Access Error) while interrupts disabled, Error state +pc: f0041298 npc: f004129c +%g0-7: 00000000 f02441a8 04400fc2 000001e2 00000027 f0243b88 00000000 f0244020 +%o0-7: ffff8000 00008000 00000f00 044000c1 f0258518 ffeec000 fbe3a4b8 f0041be4 +%l0-7: 04400fc1 f0041c78 f0041c7c 00000002 0000010f 00000002 0000002a fbe39f78 +%i0-7: ffff8000 00008000 00000f00 044000c2 00000000 ffeec000 fbe3a020 f0041be4 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 04000fc1 (icc: ---- SPE: SP-) wim: 00000002 +fsr: 00000000 y: 00000000 +``` +Additional information: + diff --git a/results/classifier/deepseek-2/output/boot/2044 b/results/classifier/deepseek-2/output/boot/2044 new file mode 100644 index 000000000..d57546975 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2044 @@ -0,0 +1,6 @@ + +HP-UX 10.20 doesn't boot on QEMU 8.2.0-rc4 +Description of problem: +After update QEMU for v8.2.0-rc4 existing HP-UX 10.20 installation doesn't work anymore. I also tried to boot the installation media and SeaBIOS stays in loop. +Additional information: +# diff --git a/results/classifier/deepseek-2/output/boot/206 b/results/classifier/deepseek-2/output/boot/206 new file mode 100644 index 000000000..42501cf55 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/2070 b/results/classifier/deepseek-2/output/boot/2070 new file mode 100644 index 000000000..d3df3c126 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2070 @@ -0,0 +1,10 @@ + +TCG acceleration + EDK2 + Secure Boot hangs on boot since qemu 8.2 +Description of problem: +Since qemu 8.2, using TCG acceleration in combination with EDK2-OVMF UEFI Secure Boot firmware hangs on boot. qemu freezes and keeps a full CPU core busy at 100% while it hangs. The issue does not occur when using KVM acceleration. It also does not occur when not using EDK2-OVMF UEFI firmware. It also does not occur when using the non secure boot EDK2-OVMF UEFI firmware. +Steps to reproduce: +1. `git clone https://github.com/systemd/mkosi` +2. `cd mkosi` +3. `bin/mkosi --tools-tree=default --tools-tree-distribution=arch --qemu-kvm=no --qemu-firmware=uefi --debug -f qemu` +Additional information: + diff --git a/results/classifier/deepseek-2/output/boot/2090 b/results/classifier/deepseek-2/output/boot/2090 new file mode 100644 index 000000000..65e212078 --- /dev/null +++ b/results/classifier/deepseek-2/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. + + + +## diff --git a/results/classifier/deepseek-2/output/boot/2091 b/results/classifier/deepseek-2/output/boot/2091 new file mode 100644 index 000000000..11f17c35b --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2091 @@ -0,0 +1,4 @@ + +m68k: virt: Pass the configured cpu type via bootinfo instead of the default 68040 +Additional information: + diff --git a/results/classifier/deepseek-2/output/boot/2109 b/results/classifier/deepseek-2/output/boot/2109 new file mode 100644 index 000000000..9812456be --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/2135 b/results/classifier/deepseek-2/output/boot/2135 new file mode 100644 index 000000000..a8565a99a --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2135 @@ -0,0 +1,25 @@ + +Looking for ways to bypass MPS3-AN547 bootram size limit +Description of problem: +Could not boot MPS3-AN547 machine with images larger than 512KiB. + +I've tried to move part of the symbols to other memory area, but the memories were discontinuous and this resulted in a large image which covers the reserved area in-between and wouldn't boot. I'm looking for advice on how to put more code in bootram. + +I've also noticed the 8MB QSPI rom area, but AN547 does not have the remapping capability as AN524 and cannot use that as bootram. What is the best way to solve this? +Steps to reproduce: +1.Generate an image which goes beyond 0x00000000~(0+512K) + +2.```qemu-system-arm -M mps3-an547 -nographic -kernel big-image.bin``` + +3."```qemu-system-arm: Could not load kernel 'nuttx/nuttx.bin'```" +Additional information: +Current working linker script: +``` +MEMORY +{ + flash (rx) : ORIGIN = 0x00000000, LENGTH = 512K + sram1 (rwx) : ORIGIN = 0x01000000, LENGTH = 2M + sram2 (rwx) : ORIGIN = 0x21000000, LENGTH = 4M +} +``` +Problem X is that the flash will overflow. diff --git a/results/classifier/deepseek-2/output/boot/2204 b/results/classifier/deepseek-2/output/boot/2204 new file mode 100644 index 000000000..bd3000679 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2204 @@ -0,0 +1,74 @@ + +Hyper-V on Windows Server 2022 cannot load images converted from OVA to VHDX by qemu-img: Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device +Description of problem: +We have reference OVA image: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova and we want to convert it to VMDX format. +Steps to reproduce: +I downloaded reference OVA and converted it to VMDX with three possible options. + +With subformat dynamic: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=dynamic fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +And without it: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +And with explicitly setting fixed: +``` +qemu-img convert fastnetmon-ubuntu-22.04-amd64-2.0.360.0.ova -O vhdx -o subformat=fixed fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx +``` + +In all cases I tried loading images using VM of Generation 1 and Generation 2: +``` +The application encountered an error while attempting to change the state of +'New Virtual Machine'. + +'New Virtual Machine' failed to start. + +Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.. + +Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.hdx''. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.. + +Failed to open attachment 'C:\Program Files\qemu\fastnetmon_non_dynamic.vhdx'. Error: 'The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and unencrypted and must not be sparse.'. +``` + +I noticed some similarities with https://gitlab.com/qemu-project/qemu/-/issues/136 and applied workaround to fix it: +``` +fsutil sparse setflag fastnetmon-ubuntu-22.04-amd64-2.0.360.0.vhdx 0 +``` + +It started complaining that file is being used by another app. I waited long enough and then rebooted server. + +After that error changed to: +``` +Boot failure. Reboot and Select proper Boot device or Insert Boot Media in selected Boot device_ +``` + +As image: + + + +For Generation 2 error is slightly different: +``` +Virtual Machine Boot Summary +1. SCSI Disk +(0,0) +The boot loader did not load an operating system. +2. Network Adapter (00155D01770C) +A boot image was not found. +``` + +As image:  + +I tried doing conversion from VirtualBox with same OVA and it worked just fine: +``` +VBoxManage clonehd fastnetmon-ubuntu-22.04-amd64-disk1.vmdk fastnetmon.vhd --format vhd +``` + +I believe something is wrong with boot records for VMDX images. + +Example of converted VHDX with dynamic flag can be found here: https://storage.googleapis.com/fastnetmon_advanced_vm_images/fastnetmon-ubuntu-22.04-amd64-2.0.356.0.vhdx + +By Pavel Odintsov at FastNetMon.com diff --git a/results/classifier/deepseek-2/output/boot/2234 b/results/classifier/deepseek-2/output/boot/2234 new file mode 100644 index 000000000..6cbbd6245 --- /dev/null +++ b/results/classifier/deepseek-2/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)``` + + +When the bios interface loading process does succeed, it goes to the expected screen: + +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/output/boot/2235 b/results/classifier/deepseek-2/output/boot/2235 new file mode 100644 index 000000000..9cb2e5869 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/2280 b/results/classifier/deepseek-2/output/boot/2280 new file mode 100644 index 000000000..39b2c5299 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2280 @@ -0,0 +1,2 @@ + +Not Installing Properly diff --git a/results/classifier/deepseek-2/output/boot/2361 b/results/classifier/deepseek-2/output/boot/2361 new file mode 100644 index 000000000..dcbcd043c --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2361 @@ -0,0 +1,14 @@ + +-cpu host or -cpu max breaks GRUB on AMD +Description of problem: +I'm running the on an AMD Ryzen CPU host. I am emulating a Debian Bookworm image stored in a raw disk. It uses GRUB to load a large (400MB) initrd. When ran with the flag -cpu host or -cpu max, GRUB throws an out of memory error while loading the initrd. This doesn't occur when using -cpu kvm64 or excluding the -cpu flag. + +If I direct boot the initrd and kernel via -initrd and -kernel, it works fine. The image also works with -cpu host on an Intel CPU host machine. The image also works with -cpu EPYC. +Steps to reproduce: +1. Create a raw disk with a large initrd and GRUB boot loader +2. Start a qemu machine on an AMD host +3. Receive an error: out of memory +Additional information: +I could try selectively enabling CPU features, but I was wondering if the maintainers knew of any feature that might be causing this or how to list the features -cpu host enables. + +I also am not 100% that this is a QEMU bug, but it seems the only way to fix it is changing the QEMU config. diff --git a/results/classifier/deepseek-2/output/boot/2365 b/results/classifier/deepseek-2/output/boot/2365 new file mode 100644 index 000000000..bed0f8366 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/2382 b/results/classifier/deepseek-2/output/boot/2382 new file mode 100644 index 000000000..40437ecdb --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2382 @@ -0,0 +1,15 @@ + +QEMU occurs an Error when testing my DIY UEFI aarch64 kernel:Synchronous Exception at 0x00000000E46CCEAC +Description of problem: +Shows Synchronous Exception at 0x00000000E46CCEAC and the program halts. +Steps to reproduce: +1.Download the UEFIPascalOS on github. +2.run the bash buildaarch64.sh to build the kernel iso. +3.Go through the installer guide and enter the kernel. +4.Enter the account's name and password and press enter,now you can got an error that shows Synchronous Exception at 0x00000000E46CCEAC +Additional information: +(no logs,stack traces was shown for the error because logs and stack traces are not exists.) +screenshots: + +If I create two accounts,it will halt on sentence "Welcome to TYDQ System!" and give me Synchronous Exception at other numbers. +If I change the memory in virt-machine,the Synchronous Exception showing number will be changed. diff --git a/results/classifier/deepseek-2/output/boot/2393 b/results/classifier/deepseek-2/output/boot/2393 new file mode 100644 index 000000000..155877fd3 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2393 @@ -0,0 +1,21 @@ + +qemu: seabios hangs for 10~15 sec at boot with `-machine q35` +Description of problem: +Whenever i'm starting a virtual machine i'm having the issue that seabios (or at least that's what i see) hangs for about 10~15 seconds. In that time on of the cpu cores runs at 100%. +This issue isn't new actually. I'm having this already for quite some time and a i think for at least the last 2 major versions. I haven't looked into it since it isn't a big issue, just annoying. +Today i've looked into it and as far as i can see, this issue is always present with the flag `-machine q35`, which is the default for my vm's. If i set it to `-machine pc`, booting works as expected. However i also found a "workaround" where the vm's starting immediately (with `-machine q35` enabled), which is by simply adding a iso image to the command line (via -cdrom) - even though it's not used. + +This means: +- 15 sec delay: qemu-system-x86_64 -machine q35 +- works immediately: qemu-system-x86_64 -machine q35 -cdrom /mnt/data/vm/isos/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20230303-Media.iso + +Please note that most of my vm's usually start booting from a kernel image directly (-kernel /mnt/data/vm/kernel/gentoo-latest -initrd /mnt/data/vm/kernel/initrd-v5.cpio.gz) - but even in that case settings a cdrom (image) would fix the issue. +Also, the image needs to be a valid one, if i set an empty file or /dev/null the issue would remain. +Further more, i have the same issue on a second computer. This also runs on Gentoo Linux and is also a AMD Ryzen. (in case this is relevant) +Steps to reproduce: +1. qemu-system-x86_64 -machine q35 +2. wait about 10-15sec before boot continues +Additional information: +I was thinking to add an Screenshot of the hanging boot process, but the only text written there is: +SeaBIOS (version 1.16.0-20220807_005459-localhost) +with a blinking cursor below diff --git a/results/classifier/deepseek-2/output/boot/2464 b/results/classifier/deepseek-2/output/boot/2464 new file mode 100644 index 000000000..1553595be --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2464 @@ -0,0 +1,12 @@ + +"rc4030: invalid read at 0xf0-0xf8" shows up, then NT MIPS bluescreens +Description of problem: +The problem is fairly nondescript, but it seems to be a chipset regression that popped up between QEMU 8 and QEMU 9. I had a Windows NT 4 VM that I tried booting in the latest QEMU update after a while of not using it, and it just flat-out refused to do that, outputting the ``INACCESSIBLE_BOOT_DEVICE`` error. Any attempt to boot from the hard drive or reinstall the OS from the CD image would return the same bluescreen, and would show the very message shown in the title in the process log. +Steps to reproduce: +1. Download a Windows NT 3.5x/4.0 ISO. +2. Create a disk image ≤2GB in size. +3. Enter the command above. +4. Go through the preparatory setup, as described in [here](https://computernewb.com/wiki/QEMU/Guests/Windows_NT_3.x-4.0_(MIPS)). (ignore the networking switches, or replace ``dp83932`` with ``ne2k_isa``) +5. Launch the installer by running ``cd:\mips\setupldr``. +Additional information: + diff --git a/results/classifier/deepseek-2/output/boot/2486 b/results/classifier/deepseek-2/output/boot/2486 new file mode 100644 index 000000000..1456bbc8c --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2486 @@ -0,0 +1,13 @@ + +RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message +Description of problem: +The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified. +Disabling the extension using f=false does not actually disable it as shown by the zfinx error message. +Eg. Unsupported extension is explicitly rejected +``` +> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out +qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found +``` +Steps to reproduce: +1. Compile any riscv binary like: `int main() {}` +2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out` diff --git a/results/classifier/deepseek-2/output/boot/2502 b/results/classifier/deepseek-2/output/boot/2502 new file mode 100644 index 000000000..b4905756d --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2502 @@ -0,0 +1,14 @@ + +Old amd64 Ubuntu won't start +Description of problem: +While taking a trip down memory lane, I noticed that old Ubuntu amd64 live CDs won't boot in qemu-system-x86_64, while i386 ones work fine. I can confirm this for 6.06 and prior releases, while 8.04 and forward are OK (I don't have interim releases isos). +Steps to reproduce: +1. Launch qemu-system-x86_64 with Ubuntu 6.06.1 amd64 live CD +2. Press "Start or install Ubuntu" +3. PANIC: early exception rip (etc, please see screenshot below) +Additional information: + + +I tried a few versions of QEMU and I can tell you that everything worked fine in 7.0.0 and it first broke in 7.1.0. I don't have a more precise bisect, sorry. I also tried in Fedora 40 with QEMU 8.2.2 and I have the same issue, so I don't think it's distro related. + +On the other hand, on a completely different PC with an Intel Core i3-330M I have no issue at all, even with QEMU 8.2.3, so it might be AMD/Ryzen related. diff --git a/results/classifier/deepseek-2/output/boot/2558 b/results/classifier/deepseek-2/output/boot/2558 new file mode 100644 index 000000000..5f7ce5479 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2558 @@ -0,0 +1,66 @@ + +riscv64: Ubuntu doesn't boot with EDK2, although it boots with u-boot +Description of problem: +Ubuntu doesn't boot with `edk2-riscv-code.fd`: + +```bash +wget https://cloud-images.ubuntu.com/noble/20240822/noble-server-cloudimg-riscv64.img + +qemu-system-riscv64 -M virt -m 2048 -nographic -hda noble-server-cloudimg-riscv64.img \ + -drive if=pflash,format=raw,readonly=on,file=/usr/local/share/qemu/edk2-riscv-code.fd +``` + + +``` +Loading Linux 6.8.0-41-generic ... +Loading initial ramdisk ... +InstallProtocolInterface: 4006C0C1-FCB3-403E-996D-4A6C8724E06D FDB3F3C8 +InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B FDB3F380 +[Security] 3rd party image[0] can be loaded after EndOfDxe: MemoryMapped(0x2,0xF9CC4000,0xFC194000). +InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B FF29C2C0 +Loading driver at 0x000F732C000 EntryPoint=0x000F817FEA6 +InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF FF29CC18 +ProtectUefiImageCommon - 0xFF29C2C0 + - 0x00000000F732C000 - 0x0000000002598000 +SetUefiImageMemoryAttributes - 0x00000000F732C000 - 0x0000000000001000 (0x0000000000004000) +SetUefiImageMemoryAttributes - 0x00000000F732D000 - 0x0000000000FFF000 (0x0000000000020000) +SetUefiImageMemoryAttributes - 0x00000000F832C000 - 0x0000000001598000 (0x0000000000004000) +TimerDriverSetTimerPeriod(0x0) +SetUefiImageMemoryAttributes - 0x00000000FFEC7000 - 0x000000000000C000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFEBC000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFEAC000 - 0x0000000000010000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFEA1000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE84000 - 0x000000000001D000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE79000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE6E000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE63000 - 0x000000000000B000 (0x0000000000000000) +SetUefiImageMemoryAttributes - 0x00000000FFE59000 - 0x000000000000A000 (0x0000000000000000) +(hangs here) +``` + +The same disk image still boots when `uboot.elf` is specified as the kernel image: + +```bash +wget https://github.com/lima-vm/u-boot-qemu-mirror/releases/download/2023.07%2Bdfsg-1/qemu-riscv64_smode_uboot.elf + +qemu-system-riscv64 -M virt -m 2048 -nographic -hda noble-server-cloudimg-riscv64.img \ + -kernel qemu-riscv64_smode_uboot.elf +``` + +``` +Loading Linux 6.8.0-41-generic ... +Loading initial ramdisk ... +syscon-poweroff poweroff: pm_power_off already claimed for sbi_srst_power_off +-.mount +etc-machine\x2did.mount +systemd-journald.service +dev-hugepages.mount +... +Ubuntu 24.04 LTS ubuntu ttyS0 + +ubuntu login: +``` +Steps to reproduce: +See above +Additional information: + diff --git a/results/classifier/deepseek-2/output/boot/260 b/results/classifier/deepseek-2/output/boot/260 new file mode 100644 index 000000000..a3f2f8618 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/260 @@ -0,0 +1,2 @@ + +qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso diff --git a/results/classifier/deepseek-2/output/boot/2686 b/results/classifier/deepseek-2/output/boot/2686 new file mode 100644 index 000000000..3c51c91e7 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/269 b/results/classifier/deepseek-2/output/boot/269 new file mode 100644 index 000000000..fbadfa976 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/269 @@ -0,0 +1,2 @@ + +AIX 7.2 TL4 SP1 cannot IPL with QEMU >2.11.2 ppc64-softmmu diff --git a/results/classifier/deepseek-2/output/boot/2700 b/results/classifier/deepseek-2/output/boot/2700 new file mode 100644 index 000000000..1e0512f03 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/2729 b/results/classifier/deepseek-2/output/boot/2729 new file mode 100644 index 000000000..65370d8a5 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2729 @@ -0,0 +1,75 @@ + +qemu-system-aarch64 -M raspi4b -- no valid DTB provided in x0 register +Description of problem: +When starting `qemu-system-aarch64 -M raspi4b`, no valid DTB is provided in x0. +Steps to reproduce: +Make a simple binary to loop forever + +``` +$ cat loop.c +void _start(void) +{ + for(;;) + ; +} +$ aarch64-linux-gnu-gcc loop.c -nostdlib +$ aarch64-linux-gnu-objcopy -O binary a.out loop.bin +``` + +Start qemu for debugging and start gdb + +``` +$ qemu-system-aarch64 -S -s -M raspi4b -kernel loop.bin +# in another terminal +$ aarch64-linux-gnu-gdb +(gdb) target remote :1234 +Remote debugging using :1234 +warning: No executable has been specified and target does not support +determining executable automatically. Try using the "file" command. +0x0000000000000000 in ?? () +(gdb) watch *$x0 +Watchpoint 3: *$x0 +(gdb) watch $x0 +Watchpoint 4: $x0 +(gdb) x/2x$x0 +0x0: 0x580000c0 0xaa1f03e1 +(gdb) si + +Thread 1 hit Watchpoint 3: *$x0 + +Old value = 1476395200 +New value = 5 + +Thread 1 hit Watchpoint 4: $x0 + +Old value = 0 +New value = 256 +0x0000000000000004 in ?? () +(gdb) x/2x$x0 +0x100: 0x00000005 0x54410001 +(gdb) si +0x0000000000000008 in ?? () +(gdb) si +0x000000000000000c in ?? () +(gdb) si +0x000000000000000c in ?? () +(gdb) si +0x0000000000000010 in ?? () +(gdb) si +0x0000000000000014 in ?? () +(gdb) si +0x0000000000080000 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) si +0x0000000000000200 in ?? () +(gdb) x/2x$x0 +0x100: 0x00000005 0x54410001 +(gdb) +``` + +Note that at no time is a valid DTB provided in x0. I expected to see the DTB magic 0xd00dfeed (or 0xedfe0dd0) at the memory pointed to by x0 diff --git a/results/classifier/deepseek-2/output/boot/2739 b/results/classifier/deepseek-2/output/boot/2739 new file mode 100644 index 000000000..554664e5b --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2739 @@ -0,0 +1,4 @@ + +Feature: Emulate GRUB2's initrd16 newc: feature for dynamic initrd generation +Additional information: +This feature is used in boot environments like WINPE, where GRUB2 leverages `initrd16` with `newc:` to load `wimboot` and then dynamically create an initrd containing necessary files for booting a Windows PE environment from a WIM image. Emulating this in QEMU would greatly improve the ability to test and debug such setups. diff --git a/results/classifier/deepseek-2/output/boot/2810 b/results/classifier/deepseek-2/output/boot/2810 new file mode 100644 index 000000000..d76ecd723 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2810 @@ -0,0 +1,2 @@ + +Boot zboot images on riscv64 and loogarch64 diff --git a/results/classifier/deepseek-2/output/boot/2840 b/results/classifier/deepseek-2/output/boot/2840 new file mode 100644 index 000000000..ed83c6068 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/2842 b/results/classifier/deepseek-2/output/boot/2842 new file mode 100644 index 000000000..f5286a8c0 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2842 @@ -0,0 +1,2 @@ + +RX System emulator boot, kernel images and device tree blob are missing diff --git a/results/classifier/deepseek-2/output/boot/2847 b/results/classifier/deepseek-2/output/boot/2847 new file mode 100644 index 000000000..20da2f6d2 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2847 @@ -0,0 +1,2 @@ + +Provide short option for UEFI firmware diff --git a/results/classifier/deepseek-2/output/boot/2893 b/results/classifier/deepseek-2/output/boot/2893 new file mode 100644 index 000000000..405e9aa66 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2893 @@ -0,0 +1,13 @@ + +with m4 mac mini windows 11 arm 64 iso not booting for installation +Description of problem: +Trying to run win11 arm 64 version in m4 mac mini and the ios failed to boot + +i went to the efi shell and tried to boot from there and it just hangs no problem reported + +when i attach the serial to stdio i get the error convertprogress failed to find range errors +Steps to reproduce: +1. In m4 mac mini download win11 arm 64 iso from microsoft site +2. run the above mentioned command and you will see that it does not boot + +/label ~"kind::Bug" diff --git a/results/classifier/deepseek-2/output/boot/2918 b/results/classifier/deepseek-2/output/boot/2918 new file mode 100644 index 000000000..98ed212d2 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2918 @@ -0,0 +1,2 @@ + +qemu-system-hppa hangs on 64bit installations (machine -C3700) diff --git a/results/classifier/deepseek-2/output/boot/2930 b/results/classifier/deepseek-2/output/boot/2930 new file mode 100644 index 000000000..ffbbc9e31 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2930 @@ -0,0 +1,2 @@ + +Versions after QEMU9.0 cannot boot vxworks on sifive_u diff --git a/results/classifier/deepseek-2/output/boot/2940 b/results/classifier/deepseek-2/output/boot/2940 new file mode 100644 index 000000000..322aaaf56 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/2957 b/results/classifier/deepseek-2/output/boot/2957 new file mode 100644 index 000000000..8e62fab90 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2957 @@ -0,0 +1,29 @@ + +qemu-system-riscv32: Some ROM regions are overlapping +Description of problem: +Booting the image produces: +``` +qemu-system-riscv32: Some ROM regions are overlapping +These ROM regions might have been loaded by direct user request or by default. +They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. +Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. + +The following two regions overlap (in the memory address space): + output/images/fw_jump.elf ELF program header segment 1 (addresses 0x0000000000000000 - 0x00000000000278cc) + mrom.reset (addresses 0x0000000000001000 - 0x0000000000001028) +``` +Steps to reproduce: +1. `make qemu_riscv32_virt_defconfig` +2. `make` +3. `qemu-system-riscv32 \ +-M virt -nographic \ +-bios output/images/fw_jump.elf \ +-kernel output/images/Image \ +-append "root=/dev/vda ro" \ +-drive file=output/images/rootfs.ext2,format=raw,id=hd0 \ +-device virtio-blk-device,drive=hd0 \ +-netdev user,id=net0 -device virtio-net-device,netdev=net0` +Additional information: +Changing `-bios output/images/fw_jump.elf` to `-bios output/images/fw_jump.bin` or `-bios output/images/fw_dynamic.bin` resolves the issue. + +Similar issue observed elsewhere, e.g. here [https://github.com/riscv-software-src/opensbi/issues/372](https://github.com/riscv-software-src/opensbi/issues/372) diff --git a/results/classifier/deepseek-2/output/boot/2987 b/results/classifier/deepseek-2/output/boot/2987 new file mode 100644 index 000000000..c72a0f1f4 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/2987 @@ -0,0 +1,8 @@ + +QEMU TCG failed to boot Windows 98 Second Edition +Description of problem: +QEMU TCG failed at booting Windows 98 Second Edition 4.10.2222B. + +Bisected to commit e54ef98c8a80d16158bab4341d9a898701270528 +Additional information: + diff --git a/results/classifier/deepseek-2/output/boot/366 b/results/classifier/deepseek-2/output/boot/366 new file mode 100644 index 000000000..563fc30bc --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/366 @@ -0,0 +1,2 @@ + +How to make OVMF diff --git a/results/classifier/deepseek-2/output/boot/367 b/results/classifier/deepseek-2/output/boot/367 new file mode 100644 index 000000000..38b228c00 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/367 @@ -0,0 +1,2 @@ + +qemu-system-aarch64 crash on qemu 6.0 - Windows 10 diff --git a/results/classifier/deepseek-2/output/boot/389 b/results/classifier/deepseek-2/output/boot/389 new file mode 100644 index 000000000..37a174a65 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/389 @@ -0,0 +1,2 @@ + +Add multiboot2 support diff --git a/results/classifier/deepseek-2/output/boot/393569 b/results/classifier/deepseek-2/output/boot/393569 new file mode 100644 index 000000000..b143558b1 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/425 b/results/classifier/deepseek-2/output/boot/425 new file mode 100644 index 000000000..c4c5fca75 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/436 b/results/classifier/deepseek-2/output/boot/436 new file mode 100644 index 000000000..c1995e670 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/436 @@ -0,0 +1,2 @@ + +window 8 stuck during boot on Qemu diff --git a/results/classifier/deepseek-2/output/boot/45 b/results/classifier/deepseek-2/output/boot/45 new file mode 100644 index 000000000..4e60636d6 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/45 @@ -0,0 +1,2 @@ + +qemu-system-aarch64: no function defined to set boot device list for this architecture diff --git a/results/classifier/deepseek-2/output/boot/452 b/results/classifier/deepseek-2/output/boot/452 new file mode 100644 index 000000000..a98579275 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/452 @@ -0,0 +1,57 @@ + +Akita (and probably all Spitz-like / PXA270) platform does not load BIOS binary +Description of problem: +QEMU does not appear to load a binary file passed with the "-bios" argument for the "akita" target. This probably extends to other spitz-type systems. + +Exptected behavior: qemu loads the binary into address 0x0000. +Actual behavior: address space at 0x0000 contains only zeros. +Steps to reproduce: +Terminal 1: +``` +qemu-system-arm -M akita -bios c750.rom -s -S +``` + +Terminal 2: +``` +gdb-multiarch +target remote localhost:1234 +x/64i $pc +``` + +Result: +``` +=> 0x0: andeq r0, r0, r0 + 0x4: andeq r0, r0, r0 + 0x8: andeq r0, r0, r0 + 0xc: andeq r0, r0, r0 + 0x10: andeq r0, r0, r0 +``` + +Correct behavior (can demonstrate with virt machine): +Same as before, but start Terminal 1 with: +``` +qemu-system-arm -M akita -bios c750.rom -s -S +``` + +Result: +``` +=> 0x0: b 0x34 + 0x4: ldr pc, [pc, #156] ; 0xa8 + 0x8: ldr pc, [pc, #156] ; 0xac + 0xc: ldr pc, [pc, #156] ; 0xb0 + 0x10: ldr pc, [pc, #156] ; 0xb4 + 0x14: nop ; (mov r0, r0) + 0x18: ldr pc, [pc, #152] ; 0xb8 + 0x1c: ldr pc, [pc, #152] ; 0xbc + 0x20: mov r0, #128 ; 0x80 + 0x24: b 0x2c + 0x28: mov r0, #129 ; 0x81 + 0x2c: ldr r1, [pc, #140] ; 0xc0 + 0x30: str r0, [r1] + 0x34: mrs lr, CPSR + 0x38: bic lr, lr, #31 + 0x3c: orr lr, lr, #211 ; 0xd3 + 0x40: msr CPSR_fc, lr +``` +Additional information: +File with very tiny boot ROM: [c750-tiny.rom](/uploads/045852c8b353174bf0b7a4193d0d1be0/c750-tiny.rom) diff --git a/results/classifier/deepseek-2/output/boot/475 b/results/classifier/deepseek-2/output/boot/475 new file mode 100644 index 000000000..ef0ce7813 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/475 @@ -0,0 +1,2 @@ + +4.2 regression: ReactOS crashes on boot diff --git a/results/classifier/deepseek-2/output/boot/499 b/results/classifier/deepseek-2/output/boot/499 new file mode 100644 index 000000000..c9ac820cb --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/499 @@ -0,0 +1,2 @@ + +booting a linux guest with qemu-system-sparc with icount enabled hangs diff --git a/results/classifier/deepseek-2/output/boot/512 b/results/classifier/deepseek-2/output/boot/512 new file mode 100644 index 000000000..2597364ff --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/512 @@ -0,0 +1,2 @@ + +6.1.0-rc1 New regression (not in 6.1.0-rc0): Freezes using UEFI firmware without acceleration diff --git a/results/classifier/deepseek-2/output/boot/55 b/results/classifier/deepseek-2/output/boot/55 new file mode 100644 index 000000000..4da947109 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/55 @@ -0,0 +1,2 @@ + +Can't install Windows 7 with q35 (SATA) diff --git a/results/classifier/deepseek-2/output/boot/551545 b/results/classifier/deepseek-2/output/boot/551545 new file mode 100644 index 000000000..7b2423600 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/586175 b/results/classifier/deepseek-2/output/boot/586175 new file mode 100644 index 000000000..f7c188f7d --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/588735 b/results/classifier/deepseek-2/output/boot/588735 new file mode 100644 index 000000000..db5831188 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/588748 b/results/classifier/deepseek-2/output/boot/588748 new file mode 100644 index 000000000..55d9b38f3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/598 b/results/classifier/deepseek-2/output/boot/598 new file mode 100644 index 000000000..27c918c94 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/598 @@ -0,0 +1,2 @@ + +QEMU boot kernel for ppc e300c3 problem diff --git a/results/classifier/deepseek-2/output/boot/599 b/results/classifier/deepseek-2/output/boot/599 new file mode 100644 index 000000000..db11c3096 --- /dev/null +++ b/results/classifier/deepseek-2/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. + + + +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/output/boot/622367 b/results/classifier/deepseek-2/output/boot/622367 new file mode 100644 index 000000000..c41c4d629 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/623852 b/results/classifier/deepseek-2/output/boot/623852 new file mode 100644 index 000000000..d8c2cdd0e --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/627 b/results/classifier/deepseek-2/output/boot/627 new file mode 100644 index 000000000..effc7ce3a --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/627 @@ -0,0 +1,8 @@ + +VI.EXE crashes on start under QEMU; works under BOCHS +Description of problem: +vi.exe hangs on startup; can be verified to work in bochs +Steps to reproduce: +1. Run vi.exe from DOS prompt; hang is evident immediately as ~ ~ ~ ~ doesn't show up +Additional information: +Actual [vi.exe](/uploads/d77076b8187489253c6ad8f1ab3ec247/vi.exe) attached; it's ridiculously old; the kind of thing that belongs on archive.org; I think I actually own this copy program by inheritance; but if the copyright holder objects we'll have to take it down again. :( diff --git a/results/classifier/deepseek-2/output/boot/627982 b/results/classifier/deepseek-2/output/boot/627982 new file mode 100644 index 000000000..76a969b82 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/639651 b/results/classifier/deepseek-2/output/boot/639651 new file mode 100644 index 000000000..3a8d539de --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/651 b/results/classifier/deepseek-2/output/boot/651 new file mode 100644 index 000000000..89c06eb6f --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/651 @@ -0,0 +1,2 @@ + +powerpc: Starting machine ref405ep fails with "Could not load PowerPC BIOS 'ppc405_rom.bin'" diff --git a/results/classifier/deepseek-2/output/boot/665 b/results/classifier/deepseek-2/output/boot/665 new file mode 100644 index 000000000..e56540f4c --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/665 @@ -0,0 +1,53 @@ + +Cannot boot from emulated NVMe with seabios +Description of problem: +SeaBIOS doesn't boot from NVMe disk. + +This is regression compared to version 5.1.0. The exact same SeaBIOS binary that works with QEMU 5.1.0, doesn't detect NVMe with QEMU 6.0.0, nor QEMU 6.1.0. Booting from NVMe via OVMF works on all those versions. +Steps to reproduce: +1. Start the above command +2. Press ESC to open boot menu in SeaBIOS +3. Observe lack of NVMe entry +Additional information: +I've bisected it to this commit: +``` +7f0f1acedf159d00684d495d7a14d52220c1d16b is the first bad commit +commit 7f0f1acedf159d00684d495d7a14d52220c1d16b +Author: Klaus Jensen <k.jensen@samsung.com> +Date: Wed Jun 26 08:51:06 2019 +0200 + + hw/block/nvme: support multiple namespaces + + This adds support for multiple namespaces by introducing a new 'nvme-ns' + device model. The nvme device creates a bus named from the device name + ('id'). The nvme-ns devices then connect to this and registers + themselves with the nvme device. + + This changes how an nvme device is created. Example with two namespaces: + + -drive file=nvme0n1.img,if=none,id=disk1 + -drive file=nvme0n2.img,if=none,id=disk2 + -device nvme,serial=deadbeef,id=nvme0 + -device nvme-ns,drive=disk1,bus=nvme0,nsid=1 + -device nvme-ns,drive=disk2,bus=nvme0,nsid=2 + + The drive property is kept on the nvme device to keep the change + backward compatible, but the property is now optional. Specifying a + drive for the nvme device will always create the namespace with nsid 1. + + Signed-off-by: Klaus Jensen <k.jensen@samsung.com> + Reviewed-by: Keith Busch <kbusch@kernel.org> + Reviewed-by: Minwoo Im <minwoo.im.dev@gmail.com> + + hw/block/meson.build | 2 +- + hw/block/nvme-ns.c | 167 ++++++++++++++++++++++++++++++++++ + hw/block/nvme-ns.h | 74 +++++++++++++++ + hw/block/nvme.c | 245 ++++++++++++++++++++++++++++++++------------------ + hw/block/nvme.h | 46 +++++----- + hw/block/trace-events | 6 +- + 6 files changed, 426 insertions(+), 114 deletions(-) + create mode 100644 hw/block/nvme-ns.c + create mode 100644 hw/block/nvme-ns.h +``` + +Using `-device nvme-ns` as shown above doesn't help either. diff --git a/results/classifier/deepseek-2/output/boot/670 b/results/classifier/deepseek-2/output/boot/670 new file mode 100644 index 000000000..f875dcbce --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/673 b/results/classifier/deepseek-2/output/boot/673 new file mode 100644 index 000000000..170ff9339 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/673 @@ -0,0 +1,11 @@ + +I can no longer boot with -kernel and -initrd +Description of problem: +The kernel refuses to mount the initramfs and proceeds to kernel panic. i didnt have this problem until qemu updated +Steps to reproduce: +I have put it all in the git repo of my project +1. git clone https://github.com/oknowaen/ltl-initramfs.git +2. cd ltl-initramfs +3. make (will start automatically)! +Additional information: +[Screenshot_20211016_182355](/uploads/c04094f5bcccadc3f8473f2ea6fc864d/Screenshot_20211016_182355.png) diff --git a/results/classifier/deepseek-2/output/boot/679 b/results/classifier/deepseek-2/output/boot/679 new file mode 100644 index 000000000..a18b1bdec --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/679 @@ -0,0 +1,2 @@ + +powerpc/e500: QEMU freeze without any output when kernel size is a bit big diff --git a/results/classifier/deepseek-2/output/boot/697 b/results/classifier/deepseek-2/output/boot/697 new file mode 100644 index 000000000..dfa83e892 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/723460 b/results/classifier/deepseek-2/output/boot/723460 new file mode 100644 index 000000000..63c30c48d --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/740 b/results/classifier/deepseek-2/output/boot/740 new file mode 100644 index 000000000..0682cdda0 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/740 @@ -0,0 +1,28 @@ + +on single core Raspberry Pi, qemu-system-sparc appears to hang in bios +Description of problem: +I suspect it to be a race condition related to running on the slow single core Raspberry Pi, as I haven't managed to reproduce on x86 even when using taskset to tie qemu to a single core. + +The problem occurs about 4 out of 5 runs on qemu 5.2 (raspbian bullseye) and so far 100% of the time on qemu 6.1. + +About five seconds after start the sparc bios gets as far as `ttya initialized` and then appears to hang indefinitely. + +Instead, it should continue after about 3 more seconds with: +``` +Probing Memory Bank #0 32 Megabytes +Probing Memory Bank #1 Nothing there +Probing Memory Bank #2 Nothing there +Probing Memory Bank #3 Nothing there +``` + +See below for workaround. +Steps to reproduce: +1. Need a single core Raspberry Pi running raspbian, such as Raspberry Pi 1 or Zero +2. Download ss5.bin from https://github.com/andarazoroflove/sparc/raw/master/ss5.bin +3. Run the command: +``` +qemu-system-sparc -m 32 -bios ss5.bin -nographic +``` +After about 5 seconds of output it hangs at `ttya initialized` +Additional information: +## diff --git a/results/classifier/deepseek-2/output/boot/745 b/results/classifier/deepseek-2/output/boot/745 new file mode 100644 index 000000000..b606c77cb --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/745 @@ -0,0 +1,37 @@ + +NVRAM is not persistent across coldboots without attached r/w FAT32 hard drive +Description of problem: +NVRAM variables are not persistent across coldboots without an attached readable / writable FAT32 hard drive. +Steps to reproduce: +Without hard drive: +1. Start VM as above ("without hard drive attached"), and enter EFI shell. +2. Dump the contents of a NVRAM variable, e.g. Lang. Note the contents. +3. Edit the contents of that variable. +4. Shutdown and restart the VM (cold reboot), and enter the EFI shell. +5. Dump the contents of the same NVRAM variable. The contents have reverted to what they were in Step 2. + +With hard drive: +1. Start VM as above ("with hard drive attached"), and enter EFI shell. +2. Navigate to the hard drive filesystem, e.g. FS0. +3. List the files in the filesystem. If NvVars exists, note the modification time. +4. Edit the contents of a NVRAM variable, e.g. Lang. +5. List the files of the filesystem. The NvVars file either now exists, or has notably been modified since Step 3. +Additional information: +OVMF blobs used: Those found in the Debian Sid package "ovmf_2021.11_rc1-1_all.deb" (https://packages.debian.org/sid/ovmf) + +Note that, without a hard drive attached, edited NVRAM variables persist across warm reboots, e.g. via the EFI shell command `reset`. + +I have not tested filesystem formats other than FAT32 with the attached hard drive, though I assume that would be futile due to the UEFI specification stating that EFI only supports FAT-based filesystems by default. + +Without HDD attached, before cold reboot: + + +Without HDD attached, after cold reboot: + + +With HDD attached (note modification date / time of NvVars): + + +This issue leads to modern macOS's installation process failing, as it relies on being able to modify NVRAM variables to know how far along in the installation process it is. Without these variables, the installation process will loop indefinitely, as it can't know when to move on to the next part of the overall process. + +Let me know if more information is needed, or if this is an issue better suited for the OVMF bug tracker (which I do not know the location of). diff --git a/results/classifier/deepseek-2/output/boot/756 b/results/classifier/deepseek-2/output/boot/756 new file mode 100644 index 000000000..ed130ccbd --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/756 @@ -0,0 +1,2 @@ + +qemu-system-m68k -M q800 -bios /dev/null segfaults diff --git a/results/classifier/deepseek-2/output/boot/760956 b/results/classifier/deepseek-2/output/boot/760956 new file mode 100644 index 000000000..e205faf0f --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/818647 b/results/classifier/deepseek-2/output/boot/818647 new file mode 100644 index 000000000..7e787b5f3 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/825776 b/results/classifier/deepseek-2/output/boot/825776 new file mode 100644 index 000000000..05e3d6256 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/830833 b/results/classifier/deepseek-2/output/boot/830833 new file mode 100644 index 000000000..84180d2f4 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/833658 b/results/classifier/deepseek-2/output/boot/833658 new file mode 100644 index 000000000..2c53de0b2 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/855 b/results/classifier/deepseek-2/output/boot/855 new file mode 100644 index 000000000..c2dbdd97f --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/855 @@ -0,0 +1,18 @@ + +Prebuilt seabios vgabios-stdvga binary causes onboot kernel panics for freebsd 10.0 +Description of problem: +FreeBSD 10.0 panics on boot since commit: `0221d73ce6a8e075adaa0a35a6ef853d2652b855`, see my attached screenshot of the panic. +I digged a bit into what specifically causes the issue, it seems to be caused by the precompiled `vgabios-stdvga.bin`. +I don't see this issue come up when I compile the binary myself via the `roms/` folder with different versions of gcc via gcc docker containers. +But once I compile the `vgabios-stdvga` from the `roms/` folder with a more modern Ubuntu version (21.10) using gcc 11.2, I also get panics on my `vgabios-stdvga`. +At first I thought it was caused by a different gcc version, but since the buster gcc docker container images create correctly functioning `vgabios-stdvga.bin` binaries, I think this is caused by a newer version of the linker coming from the `binutils` package. + +My local Ubuntu version has version 2.37 of the binutils package, the `gcc:11.2` container which compiles a correct `vgabios-stdvga.bin` has version `2.35.2` of the binutils package. + + +Steps to reproduce: +1. Compile any version after the mentioned commit using the precompiled seabios binaries +2. Try to boot freebsd 10.0-RELEASE +3. Kernel panic because of a page vault during the vesa module load. +Additional information: +https://mfsbsd.vx.sk/files/iso/10/amd64/mfsbsd-10.0-RELEASE-amd64.iso diff --git a/results/classifier/deepseek-2/output/boot/893 b/results/classifier/deepseek-2/output/boot/893 new file mode 100644 index 000000000..15ceb621a --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/893 @@ -0,0 +1,2 @@ + +Cannot boot and set rhel7 or 8 s390x on Redhat 8(Host OS) using qemu-system-s390x diff --git a/results/classifier/deepseek-2/output/boot/902 b/results/classifier/deepseek-2/output/boot/902 new file mode 100644 index 000000000..8cd1226e7 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/902 @@ -0,0 +1,2 @@ + +BootLinuxS390X test failing due to a TCG bug diff --git a/results/classifier/deepseek-2/output/boot/906 b/results/classifier/deepseek-2/output/boot/906 new file mode 100644 index 000000000..4ea14f813 --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/906 @@ -0,0 +1,2 @@ + +Cannot IPL this ISO image diff --git a/results/classifier/deepseek-2/output/boot/966316 b/results/classifier/deepseek-2/output/boot/966316 new file mode 100644 index 000000000..4a5365d60 --- /dev/null +++ b/results/classifier/deepseek-2/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/output/boot/992 b/results/classifier/deepseek-2/output/boot/992 new file mode 100644 index 000000000..be81d78db --- /dev/null +++ b/results/classifier/deepseek-2/output/boot/992 @@ -0,0 +1,21 @@ + +qemu-system-riscv64: Some ROM regions are overlapping When memory set <= 16 +Description of problem: + +Steps to reproduce: +1. Build the qemu +2. run `./build/riscv64-softmmu/qemu-system-riscv64 --nographic -machine virt -m 16` +3. got error message: +``` +qemu-system-riscv64: Some ROM regions are overlapping +These ROM regions might have been loaded by direct user request or by default. +They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. +Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. + +The following two regions overlap (in the memory address space): + /home/shiroko/Developments/qemu/build/pc-bios/opensbi-riscv64-generic-fw_dynamic.bin (addresses 0x0000000080000000 - 0x0000000080019b50) + fdt (addresses 0x0000000080000000 - 0x0000000080100000) +``` +Additional information: +Using `./build/riscv64-softmmu/qemu-system-riscv64 --nographic -machine virt -m 17` could bootup and seen OpenSBI messages. +This problem appears on qemu-system-riscv32 too. diff --git a/results/classifier/deepseek-2/output/boot/994 b/results/classifier/deepseek-2/output/boot/994 new file mode 100644 index 000000000..9bdedccc0 --- /dev/null +++ b/results/classifier/deepseek-2/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 |