On 04/07/2010 12:39 PM, Laine Stump wrote:
This patch adds a 1 second sleep after telling qemu to start the restore operation and before telling qemu to start up the CPUs. Without this sleep, my hardware would end up with the CPUs started before the restore was started, leading to random (but never good) behavior. Apparently this is caused by slow hardware, as I haven't heard of anyone else experiencing this problem.
Is there a BZ number or anything else we can list in the commit message showing that we've informed the qemu folks about their lack of a reliable notification that they are ready for the restore? ACK. But can you squash this in first? Otherwise, the usleep(1000000) will silently become a no-op on mingw, rather than sleeping for a second. diff --git i/bootstrap.conf w/bootstrap.conf index ac2f8e6..d55dc71 100644 --- i/bootstrap.conf +++ w/bootstrap.conf @@ -56,6 +56,7 @@ strsep sys_stat time_r useless-if-before-free +usleep vasprintf verify vc-list-files -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org