1 files changed, 74 insertions, 0 deletions
diff --git a/results/classifier/118/virtual/1359394 b/results/classifier/118/virtual/1359394
new file mode 100644
index 000000000..fb9ae95c7
--- /dev/null
+++ b/results/classifier/118/virtual/1359394
@@ -0,0 +1,74 @@
+virtual: 0.822
+device: 0.786
+boot: 0.780
+mistranslation: 0.678
+performance: 0.484
+semantic: 0.481
+hypervisor: 0.439
+graphic: 0.418
+architecture: 0.372
+PID: 0.339
+user-level: 0.320
+ppc: 0.301
+kernel: 0.287
+x86: 0.271
+i386: 0.265
+register: 0.239
+debug: 0.227
+socket: 0.223
+peripherals: 0.221
+vnc: 0.169
+network: 0.156
+assembly: 0.142
+KVM: 0.127
+permissions: 0.103
+VMM: 0.096
+risc-v: 0.086
+arm: 0.071
+TCG: 0.057
+files: 0.049
+
+virtio block device hangs after "virtio_blk virtio3: requests:id 0 is not a head!"
+
+The virtual machine is running block layer workloads, interrupted by unclean reboots (echo b > /proc/sysrq-trigger). Kernel version is 3.14.
+
+Sometimes, I get this message on boot:
+
+"virtio_blk virtio3: requests:id 0 is not a head!"
+
+Then, I/O to the virtio block devices just hangs.
+
+Unfortunately I don't have a test case and this is kind of hard to reproduce, but it seems related to having I/O in flight when the kernel is forced to reboot.
+
+On Wed, Aug 20, 2014 at 08:37:46PM -0000, Slava Pestov wrote:
+> The virtual machine is running block layer workloads, interrupted by
+> unclean reboots (echo b > /proc/sysrq-trigger). Kernel version is 3.14.
+> 
+> Sometimes, I get this message on boot:
+> 
+> "virtio_blk virtio3: requests:id 0 is not a head!"
+> 
+> Then, I/O to the virtio block devices just hangs.
+> 
+> Unfortunately I don't have a test case and this is kind of hard to
+> reproduce, but it seems related to having I/O in flight when the kernel
+> is forced to reboot.
+
+Hi Slava,
+Sounds like the virtio device was not reset properly.
+
+The guest kernel is looking for completed responses from the host.  The
+host has indicated that descriptor 0 is the next completed response but
+the guest does not remember having submitted it.
+
+Do you have a kernel stack trace when this was encountered?
+
+Stefan
+
+
+You mean a kernel stack trace when the message was printed? I don't have that but I guess I could add a dump_stack() call in there.
+
+Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU and the kernel?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+