1 files changed, 54 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/device/650 b/results/classifier/zero-shot/118/device/650
new file mode 100644
index 000000000..177479781
--- /dev/null
+++ b/results/classifier/zero-shot/118/device/650
@@ -0,0 +1,54 @@
+device: 0.828
+performance: 0.733
+graphic: 0.706
+hypervisor: 0.705
+peripherals: 0.690
+PID: 0.636
+socket: 0.629
+kernel: 0.609
+architecture: 0.606
+network: 0.580
+ppc: 0.557
+user-level: 0.532
+vnc: 0.529
+VMM: 0.510
+x86: 0.508
+permissions: 0.459
+semantic: 0.444
+arm: 0.443
+risc-v: 0.436
+i386: 0.411
+debug: 0.365
+register: 0.346
+files: 0.318
+boot: 0.308
+virtual: 0.301
+TCG: 0.277
+mistranslation: 0.263
+KVM: 0.221
+assembly: 0.148
+
+Monitor device_add triggers deadlock when calling drain_call_rcu on QEMU >= 6.0.0
+Description of problem:
+It hangs
+Steps to reproduce:
+1. Run the QEMU:
+   ```
+   ./qemu-system-mips64 -nographic
+   ```
+2. Enter into the QEMU monitor: press ctrl-a c
+3. Execute command `device_add` without arguments:
+```
+(qemu) device_add
+```
+4. It hangs so bad that only `kill -9` helps
+Additional information:
+I didn't test versions between 4.2.0 and 6.0.0, but I can confirm that 6.0.0, 6.1.0 and the latest master pull have this bug, while version 4.2.0 doesn't have it.
+
+I've tracked the problem and found this.
+
+1. Command `device_add` calls function `drain_call_rcu`. `drain_call_rcu` waits indefinitely for drain_complete_event.
+2. Function `cpu_exec` in accel/tcg/cpu-exec.c calls `rcu_read_lock` but does not call `rcu_read_unlock()`. `cpu_exec` just spins in its inner loop.
+3. Function `call_rcu_thread` hanged in calling the `synchronize_rcu` which calls `wait_for_readers`.
+
+If I execute `stop` command in QEMU monitor before calling `device_add` command, no hang happen.