1 files changed, 0 insertions, 57 deletions
diff --git a/results/classifier/118/performance/1569 b/results/classifier/118/performance/1569
deleted file mode 100644
index 5b0a472cb..000000000
--- a/results/classifier/118/performance/1569
+++ /dev/null
@@ -1,57 +0,0 @@
-performance: 0.883
-debug: 0.873
-semantic: 0.856
-vnc: 0.850
-boot: 0.830
-graphic: 0.828
-virtual: 0.766
-device: 0.759
-architecture: 0.751
-PID: 0.740
-ppc: 0.704
-VMM: 0.695
-permissions: 0.679
-peripherals: 0.661
-kernel: 0.660
-register: 0.660
-hypervisor: 0.650
-files: 0.646
-network: 0.617
-socket: 0.599
-assembly: 0.583
-user-level: 0.548
-risc-v: 0.512
-x86: 0.472
-arm: 0.408
-i386: 0.405
-TCG: 0.392
-KVM: 0.213
-mistranslation: 0.200
-
-NVMe FS operations hang after suspending and resuming both guest and host
-Description of problem:
-Hello and thank you for your work on QEMU!
-
-Using the NVMe driver with my Seagate FireCuda 530 2TB M.2 works fine until I encounter this problem, which is reliably reproducible for me.
-
-When I suspend the guest and then suspend (s2idle) my host all is well until I resume the guest (manually with `virsh dompmwakeup $VMNAME`, after the host has resumed). Although the guest resumes and is interactive, it seems that anything involving filesystem operations hang forever and do not return.
-
-Suspending and resuming the Linux guest seems to work perfectly if I don't suspend/resume the host.
-
-Ultimately what I'm wanting to do is share the drive between VMs with qemu-storage-daemon. I can reproduce the problem in that scenario in much the same way. Using PCI passthrough with the same VM and device works fine and doesn't exhibit this problem.
-
-Hopefully that's clear enough - let me know if there's anything else I can provide.
-Steps to reproduce:
-1. Create a VM with a dedicated NVMe disk.
-2. Boot an ISO and install to the disk.
-3. Verify that suspend and resume works when not suspending the host.
-4. Suspend the guest.
-5. Suspend the host.
-6. Wake the host.
-7. Wake the guest.
-8. Try just about anything that isn't likely already cached somewhere: `du -s /etc`.
-Additional information:
-I've attached the libvirt domain XML[1] and libvirtd debug logs for QEMU[2] ("1:qemu") that covers suspending the guest & host, resuming host & guest and doing something to cause a hang. I tried to leave enough time afterwards for any timeout to occur.
-
-1. [nvme-voidlinux.xml](/uploads/1dea47af096ce58175f7aa526eca455e/nvme-voidlinux.xml)
-2. [nvme-qemu-debug.log](/uploads/42d3bed456a795069023a61d38fa5ccd/nvme-qemu-debug.log)