diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/gemma3:12b/hypervisor/1818 | 21 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/hypervisor/1818207 | 32 | ||||
| -rw-r--r-- | results/classifier/gemma3:12b/hypervisor/1818937 | 38 |
3 files changed, 91 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/hypervisor/1818 b/results/classifier/gemma3:12b/hypervisor/1818 new file mode 100644 index 000000000..739992ca1 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1818 @@ -0,0 +1,21 @@ + +whpx does not work with hyper-v enabled +Description of problem: +I am experiencing issues with the WHPX (Windows Hypervisor Platform Accelerator) hardware acceleration in QEMU on my Windows 10 22h2 system. When I run QEMU with the `-accel whpx` option, I encounter the following problems: + +2. I receive the error message "WHPX: No accelerator found, hr=00000000" followed by "failed to initialize whpx: No space left on device." +Steps to reproduce: +1. Enable the Hyper-V feature on Windows. +2. Install the latest QEMU version +3. Run the QEMU command with the `-accel whpx` option. +Additional information: +- my cpu : intel i7 6500U +- ram : 8 gigabytes +- gpu : intel hd 520 +- drive : C: -> 200 gigabytes, D: -> 1to (c: 109 used, d: 732 used) +- emulated drive -> 50 gigabytes (500mb used) + + + + +(in french sorry) diff --git a/results/classifier/gemma3:12b/hypervisor/1818207 b/results/classifier/gemma3:12b/hypervisor/1818207 new file mode 100644 index 000000000..b79255a22 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1818207 @@ -0,0 +1,32 @@ + +[aarch64] VM status remains "running" after it's suspended + +The issue is observed on aarch64 (I didn't check x86) with latest upstream QEMU bits. + +Steps to reproduce: + +1) start guest + +2) suspend guest with this command: + +# echo mem > /sys/power/state + + Check console messages, which should indicate that guest has been suspended. + +3) check guest status through HMP command "info status": + + (qemu) info status + info status + VM status: running + +Note it's "running", which is incorrect. + +QEMU version: + +# qemu-system-aarch64 --version +QEMU emulator version 3.1.50 (v3.1.0-2203-g9403bcc) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +The issue prevents user from resuming a suspended guest through "system_wakeup" HMP command, because QEMU thinks the guest is in running state and does nothing. + +I think the issues occurs because qemu_system_wakeup_request() doesn't get called. It seems the root cause is with ACPI related code. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/hypervisor/1818937 b/results/classifier/gemma3:12b/hypervisor/1818937 new file mode 100644 index 000000000..e98218a00 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1818937 @@ -0,0 +1,38 @@ + +Crash with HV_ERROR on macOS host + +On macOS host running Windows 10 guest, qemu crashed with error message: Error: HV_ERROR. + +Host: macOS Mojave 10.14.3 (18D109) Late 2014 Mac mini presumably Core i5 4278U. +QEMU: git commit a3e3b0a7bd5de211a62cdf2d6c12b96d3c403560 +QEMU parameter: qemu-system-x86_64 -m 3000 -drive file=disk.img,if=virtio,discard=unmap -accel hvf -soundhw hda -smp 3 + +thread list +Process 56054 stopped + thread #1: tid = 0x2ffec8, 0x00007fff48d0805a vImage`vLookupTable_Planar16 + 970, queue = 'com.apple.main-thread' + thread #2: tid = 0x2ffecc, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #3: tid = 0x2ffecd, 0x00007fff79d715aa libsystem_kernel.dylib`__select + 10 + thread #4: tid = 0x2ffece, 0x00007fff79d71d9a libsystem_kernel.dylib`__sigwait + 10 +* thread #6: tid = 0x2ffed0, 0x00007fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT + thread #7: tid = 0x2ffed1, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #8: tid = 0x2ffed2, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + thread #11: tid = 0x2fff34, 0x00007fff79d6a17a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.NSEventThread' + thread #30: tid = 0x300c04, 0x00007fff79e233f8 libsystem_pthread.dylib`start_wqthread + thread #31: tid = 0x300c16, 0x00007fff79e233f8 libsystem_pthread.dylib`start_wqthread + thread #32: tid = 0x300c17, 0x0000000000000000 + thread #33: tid = 0x300c93, 0x00007fff79d6d7de libsystem_kernel.dylib`__psynch_cvwait + 10 + + +Crashed thread: + +* thread #6, stop reason = signal SIGABRT + * frame #0: 0x00007fff79d7023e libsystem_kernel.dylib`__pthread_kill + 10 + frame #1: 0x00007fff79e26c1c libsystem_pthread.dylib`pthread_kill + 285 + frame #2: 0x00007fff79cd91c9 libsystem_c.dylib`abort + 127 + frame #3: 0x000000010baa476d qemu-system-x86_64`assert_hvf_ok(ret=<unavailable>) at hvf.c:106 [opt] + frame #4: 0x000000010baa4c8f qemu-system-x86_64`hvf_vcpu_exec(cpu=0x00007f8e5283de00) at hvf.c:681 [opt] + frame #5: 0x000000010b988423 qemu-system-x86_64`qemu_hvf_cpu_thread_fn(arg=0x00007f8e5283de00) at cpus.c:1636 [opt] + frame #6: 0x000000010bd9dfce qemu-system-x86_64`qemu_thread_start(args=<unavailable>) at qemu-thread-posix.c:502 [opt] + frame #7: 0x00007fff79e24305 libsystem_pthread.dylib`_pthread_body + 126 + frame #8: 0x00007fff79e2726f libsystem_pthread.dylib`_pthread_start + 70 + frame #9: 0x00007fff79e23415 libsystem_pthread.dylib`thread_start + 13 \ No newline at end of file |