On Fri, Oct 19, 2012 at 2:55 PM, Guido Winkelmann <guido-kvml@xxxxxxxxxxxxxxxxx> wrote: > Am Donnerstag, 18. Oktober 2012, 18:05:39 schrieb Avi Kivity: >> On 10/18/2012 05:50 PM, Guido Winkelmann wrote: >> > Am Mittwoch, 17. Oktober 2012, 13:25:45 schrieb Brian Jackson: >> >> On Wednesday, October 17, 2012 10:45:14 AM Guido Winkelmann wrote: >> >> > vda1, logical block 1858771 >> >> > Oct 17 17:12:04 localhost kernel: [ 212.070600] Buffer I/O error on >> >> > device >> >> > vda1, logical block 1858772 >> >> > Oct 17 17:12:04 localhost kernel: [ 212.070602] Buffer I/O error on >> >> > device >> >> > vda1, logical block 1858773 >> >> > Oct 17 17:12:04 localhost kernel: [ 212.070605] Buffer I/O error on >> >> > device >> >> > vda1, logical block 1858774 >> >> > Oct 17 17:12:04 localhost kernel: [ 212.070607] Buffer I/O error on >> >> > device >> >> > vda1, logical block 1858775 >> >> > Oct 17 17:12:04 localhost kernel: [ 212.070610] Buffer I/O error on >> >> > device >> >> > vda1, logical block 1858776 >> >> > Oct 17 17:12:04 localhost kernel: [ 212.070612] Buffer I/O error on >> >> > device >> >> > vda1, logical block 1858777 >> >> > Oct 17 17:12:04 localhost kernel: [ 212.070615] Buffer I/O error on >> >> > device >> >> > vda1, logical block 1858778 >> >> > Oct 17 17:12:04 localhost kernel: [ 212.070617] Buffer I/O error on >> >> > device >> >> > vda1, logical block 1858779 >> >> > >> >> > (I was writing a large file at the time, to make sure I actually catch >> >> > I/O >> >> > errors as they happen) >> >> >> >> What about newer versions of qemu/kvm? But of course if those work, your >> >> next task is going to be git bisect it or file a bug with your distro >> >> that >> >> is using an ancient version of qemu/kvm. >> > >> > I've just upgraded both hosts to qemu-kvm 1.2.0 >> > (qemu-1.2.0-14.fc17.x86_64, >> > built from spec files under http://pkgs.fedoraproject.org/cgit/qemu.git/). >> > >> > The bug is still there. >> >> If you let the guest go idle (no I/O), then migrate it, then restart the >> I/O, do the errors show? > > Just tested - yes, they do. The -EIO error does not really reveal why there is a problem. You can use SystemTap probes in QEMU to find out more about the nature of the error. # stap -e 'probe qemu.kvm.bdrv_*, qemu.kvm.virtio_blk_*, qemu.kvm.paio_* { printf("%s(%s)\n", probefunc(), $$parms) }' -x $PID_OF_QEMU Output looks like this: bdrv_co_readv($arg1=0x7fb2397cc580 $arg2=0x80c $arg3=0x1) bdrv_co_io_em($arg1=0x7fb2397cc580 $arg2=0x80c $arg3=0x1 $arg4=0x0 $arg5=0x7fb239da6f60) virtio_blk_rw_complete($arg1=0x7fb23982ed10 $arg2=0x0) virtio_blk_req_complete($arg1=0x7fb23982ed10 $arg2=0x0) virtio_blk_rw_complete $arg2=-5 means -EIO so look for that that. This will reveal what is happening when the error occurs. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
