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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list