summary refs log tree commit diff stats
path: root/results/classifier/deepseek-2/output/hypervisor/1073
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
commitd0c85e36e4de67af628d54e9ab577cc3fad7796a (patch)
treef8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/deepseek-2/output/hypervisor/1073
parent7f4364274750eb8cb39a3e7493132fca1c01232e (diff)
downloadqemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz
qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip
add deepseek and gemma results
Diffstat (limited to 'results/classifier/deepseek-2/output/hypervisor/1073')
-rw-r--r--results/classifier/deepseek-2/output/hypervisor/107330
1 files changed, 30 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2/output/hypervisor/1073 b/results/classifier/deepseek-2/output/hypervisor/1073
new file mode 100644
index 000000000..c5dae0a9c
--- /dev/null
+++ b/results/classifier/deepseek-2/output/hypervisor/1073
@@ -0,0 +1,30 @@
+
+SIGABRT with -M raspi3b,accel=hvf on macOS
+Description of problem:
+There is a `SIGUSR2` or `SIGUSR1` raised which causes QEMU to abort:
+```
+(lldb) bt
+* thread #3, stop reason = signal SIGUSR2
+  * frame #0: 0x0000000184c384a4 libsystem_kernel.dylib`__sigsuspend + 8
+    frame #1: 0x0000000100b7ff34 qemu-system-aarch64`qemu_coroutine_new at coroutine-sigaltstack.c:221:9
+    frame #2: 0x0000000100b91f0c qemu-system-aarch64`qemu_coroutine_create(entry=(qemu-system-aarch64`monitor_qmp_dispatcher_co at qmp.c:211), opaque=0x0000000000000000) at qemu-coroutine.c:90:14
+    frame #3: 0x0000000100a833d8 qemu-system-aarch64`monitor_init_globals_core at monitor.c:707:25
+```
+
+I tried skipping over it with `lldb`:
+```
+(lldb) b main
+(lldb) r
+(lldb) process handle SIGUSR1 -s false -p true
+(lldb) process handle SIGUSR2 -s false -p true
+(lldb) c
+qemu-system-aarch64: Unknown Error
+```
+
+I investigated the Unknown Error and and it's actually `HV_ILLEGAL_GUEST_STATE` which is unhandled in the `assert_hvf_ok` function. From here the VM will fail.
+Steps to reproduce:
+1. Get a fake disk. Or create a fake one with: `qemu-img create -f qcow2 zero.qcow2 2G`
+2. Run QEMU with the HVF accelerator: `qemu-system-aarch64 -M raspi3b,accel=hvf -drive id=card0,if=none,format=qcow2,index=0,file=./zero.qcow2 -device sd-card,drive=card0 -serial stdio
+`
+Additional information:
+