summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/108/other/1908416
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/zero-shot/108/other/1908416')
-rw-r--r--results/classifier/zero-shot/108/other/190841663
1 files changed, 63 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1908416 b/results/classifier/zero-shot/108/other/1908416
new file mode 100644
index 000000000..d593f4e3c
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1908416
@@ -0,0 +1,63 @@
+other: 0.871
+device: 0.867
+files: 0.855
+graphic: 0.841
+semantic: 0.787
+performance: 0.781
+permissions: 0.755
+boot: 0.718
+KVM: 0.697
+debug: 0.674
+PID: 0.663
+vnc: 0.656
+network: 0.642
+socket: 0.602
+
+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!
+
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+