On Jun 20, 2014, at 1:53 PM, Paolo Bonzini <pbonz...@redhat.com> wrote:
> Il 20/06/2014 17:41, John Nielsen ha scritto: >>> > >>> > So we have a clue. Let me study the code more, I'll try to get back with >>> > a suggestion. >> Paolo, have you had an opportunity to look in to this some more? > > Not yet, sorry. > > One possibility is this though. Can you try migrating (or saving/restoring) > the guest when it's hung, and see if it resuscitates? The guest is still hung after a save/restore. # /usr/bin/qemu-system-x86_64 -machine accel=kvm -name bsdtest -m 512 -smp 2,sockets=1,cores=1,threads=2 -drive file=./20140613_FreeBSD_9.2-RELEASE_ufs.qcow2,if=none,id=drive0,format=qcow2 -device virtio-blk-pci,scsi=off,drive=drive0 -vnc 0.0.0.0:0 -net none -monitor stdio QEMU 2.0.50 monitor - type 'help' for more information (qemu) stop (qemu) savevm smphang (qemu) q # /usr/bin/qemu-system-x86_64 -machine accel=kvm -name bsdtest -m 512 -smp 2,sockets=1,cores=1,threads=2 -drive file=./20140613_FreeBSD_9.2-RELEASE_ufs.qcow2,if=none,id=drive0,format=qcow2 -device virtio-blk-pci,scsi=off,drive=drive0 -vnc 0.0.0.0:0 -net none -monitor stdio -loadvm smphang QEMU 2.0.50 monitor - type 'help' for more information (qemu) [The VNC console shows the same hung kernel screen as when I ran savevm] JN -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
