[Qemu-devel] [Bug 1359394] Re: virtio block device hangs after "virtio_blk virtio3: requests:id 0 is not a head!"

2014-08-28 Thread Slava Pestov
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. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1359394 Title: virt

[Qemu-devel] [Bug 1359394] [NEW] virtio block device hangs after "virtio_blk virtio3: requests:id 0 is not a head!"

2014-08-20 Thread Slava Pestov
Public bug reported: 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

[Qemu-devel] [Bug 1359383] [NEW] kernel panic at smpboot.c:134 when rebooting qemu with multiple cores

2014-08-20 Thread Slava Pestov
Public bug reported: Hi all, I can reproduce this with kernel 3.14 and 3.17rc1. I suspect it is a qemu issue, but I'm not sure. The test case is the following script: qemu-system-x86_64 -machine accel=kvm -pidfile /tmp/pid$$ -m 512M -smp 8,sockets=8 -kernel vmlinuz -append "init=/sbin/reboot -f

Re: [Qemu-devel] [PATCH 2/2] qemu-iotests: add multiwrite test cases

2014-07-31 Thread Slava Pestov
Why are you guys merging requests in qemu at all? Just submit them to the kernel and let the kernel do it. On Wed, Jul 30, 2014 at 1:11 AM, Stefan Hajnoczi wrote: > On Tue, Jul 29, 2014 at 4:11 PM, Eric Blake wrote: > > On 07/29/2014 06:41 AM, Stefan Hajnoczi wrote: > >> This test case covers

[Qemu-devel] [Bug 1343827] [NEW] block.c: multiwrite_merge() truncates overlapping requests

2014-07-18 Thread Slava Pestov
Public bug reported: If the list of requests passed to multiwrite_merge() contains two requests where the first is for a range of sectors that is a strict subset of the second's, the second request is truncated to end where the first starts, so the second half of the second request is lost. This