summary refs log tree commit diff stats
path: root/results/scraper/launchpad/1359394
diff options
context:
space:
mode:
Diffstat (limited to 'results/scraper/launchpad/1359394')
-rw-r--r--results/scraper/launchpad/135939444
1 files changed, 44 insertions, 0 deletions
diff --git a/results/scraper/launchpad/1359394 b/results/scraper/launchpad/1359394
new file mode 100644
index 00000000..1ab337b5
--- /dev/null
+++ b/results/scraper/launchpad/1359394
@@ -0,0 +1,44 @@
+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.]
+