From d0c85e36e4de67af628d54e9ab577cc3fad7796a Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 07:27:52 +0000 Subject: add deepseek and gemma results --- .../deepseek-2-tmp/reasoning/hypervisor/1850378 | 15 --------------- 1 file changed, 15 deletions(-) delete mode 100644 results/classifier/deepseek-2-tmp/reasoning/hypervisor/1850378 (limited to 'results/classifier/deepseek-2-tmp/reasoning/hypervisor/1850378') diff --git a/results/classifier/deepseek-2-tmp/reasoning/hypervisor/1850378 b/results/classifier/deepseek-2-tmp/reasoning/hypervisor/1850378 deleted file mode 100644 index 129be5a0..00000000 --- a/results/classifier/deepseek-2-tmp/reasoning/hypervisor/1850378 +++ /dev/null @@ -1,15 +0,0 @@ - -Okay, I need to classify this bug report into one of the given categories. Let me read through the problem again. - -The user upgraded from QEMU version 3.1.0 to 4.1.0 and noticed issues with RISC-V IPIs after enabling CPU hotplug. Specifically, when using IPIs between two cores, the 'wfi' instruction doesn't behave as expected—it either doesn't return or returns on timer interrupts even though they're disabled. - -The provided code is meant to wait for an interrupt, but it's not working reliably. The user suspects it's related to how QEMU handles communication between different core threads. - -Looking at the categories: possible options include 'mistranslation', 'assembly', 'other', and others like 'device', 'graphic', etc. - -The issue seems to be about inter-core communication, specifically with IPIs and thread handling in QEMU's RISC-V machine. The problem isn't directly related to translation or assembly lowering but rather to how the hypervisor (QEMU) manages interrupts across multiple cores. - -So the most fitting category is 'hypervisor' because it pertains to the management of virtual machines and their resources, including CPU hotplug and interrupt handling between different VM CPUs. - - -hypervisor \ No newline at end of file -- cgit v1.2.3