[libvirt] 'make check' hangs
When I run 'make check', it hangs sometimes. I use gdb to attach lt-virsh, and the following is the backtrace: (gdb) thread 1 [Switching to thread 1 (Thread 0x7fc6c04d5800 (LWP 24099))]#0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041c0b3 in vshDeinit (ctl=0x7fff015f4570) at virsh.c:17262 #2 0x00000000004248d1 in main (argc=<value optimized out>, argv=0x7fff015f4728) at virsh.c:17608 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fc6c04d4700 (LWP 24138))]#0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 #1 0x00007fc6c075359c in virEventPollRunOnce () at util/event_poll.c:619 #2 0x00007fc6c07527d7 in virEventRunDefaultImpl () at util/event.c:247 #3 0x000000000041bea3 in vshEventLoop (opaque=0x7fff015f4570) at virsh.c:16800 #4 0x00007fc6c0764702 in virThreadHelper (data=<value optimized out>) at util/threads-pthread.c:157 #5 0x0000003bdce077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003bdc2e570d in clone () from /lib64/libc.so.6 (gdb)
On Wed, Nov 30, 2011 at 11:18:23AM +0800, Wen Congyang wrote:
When I run 'make check', it hangs sometimes.
I use gdb to attach lt-virsh, and the following is the backtrace: (gdb) thread 1 [Switching to thread 1 (Thread 0x7fc6c04d5800 (LWP 24099))]#0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041c0b3 in vshDeinit (ctl=0x7fff015f4570) at virsh.c:17262 #2 0x00000000004248d1 in main (argc=<value optimized out>, argv=0x7fff015f4728) at virsh.c:17608 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fc6c04d4700 (LWP 24138))]#0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 #1 0x00007fc6c075359c in virEventPollRunOnce () at util/event_poll.c:619 #2 0x00007fc6c07527d7 in virEventRunDefaultImpl () at util/event.c:247 #3 0x000000000041bea3 in vshEventLoop (opaque=0x7fff015f4570) at virsh.c:16800 #4 0x00007fc6c0764702 in virThreadHelper (data=<value optimized out>) at util/threads-pthread.c:157 #5 0x0000003bdce077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003bdc2e570d in clone () from /lib64/libc.so.6 (gdb)
I've seen this once, for the first time yesterday, but I can't see any obvious change in either virsh, or the event code that would have caused this to start happening in the past couple of days. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Nov 30, 2011 at 09:01:28 +0000, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 11:18:23AM +0800, Wen Congyang wrote:
When I run 'make check', it hangs sometimes.
I use gdb to attach lt-virsh, and the following is the backtrace: (gdb) thread 1 [Switching to thread 1 (Thread 0x7fc6c04d5800 (LWP 24099))]#0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041c0b3 in vshDeinit (ctl=0x7fff015f4570) at virsh.c:17262 #2 0x00000000004248d1 in main (argc=<value optimized out>, argv=0x7fff015f4728) at virsh.c:17608 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fc6c04d4700 (LWP 24138))]#0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 #1 0x00007fc6c075359c in virEventPollRunOnce () at util/event_poll.c:619 #2 0x00007fc6c07527d7 in virEventRunDefaultImpl () at util/event.c:247 #3 0x000000000041bea3 in vshEventLoop (opaque=0x7fff015f4570) at virsh.c:16800 #4 0x00007fc6c0764702 in virThreadHelper (data=<value optimized out>) at util/threads-pthread.c:157 #5 0x0000003bdce077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003bdc2e570d in clone () from /lib64/libc.so.6 (gdb)
I've seen this once, for the first time yesterday, but I can't see any obvious change in either virsh, or the event code that would have caused this to start happening in the past couple of days.
Hmm, I suspect this may be caused by commit fd7e85ac6af833845aa0eb2526158c319800a0ae Author: Jiri Denemark <jdenemar@redhat.com> Date: Tue Oct 11 15:05:52 2011 +0200 virsh: Always run event loop Since virsh already implements event loop, it has to also run it. So far the event loop was only running during virsh console command. However, the commit added a special hack to prevent this from happening: @@ -17080,6 +17101,16 @@ vshDeinit(vshControl *ctl) } virResetLastError(); + if (ctl->eventLoopStarted) { + /* HACK: Add a dummy timeout to break event loop */ + int timer = virEventAddTimeout(-1, NULL, NULL, NULL); + if (timer != -1) + virEventRemoveTimeout(timer); + + virThreadJoin(&ctl->eventLoop); + ctl->eventLoopStarted = false; + } + return true; } Perhaps it's not working as expected. Jirka
On Wed, Nov 30, 2011 at 11:48:16AM +0100, Jiri Denemark wrote:
On Wed, Nov 30, 2011 at 09:01:28 +0000, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 11:18:23AM +0800, Wen Congyang wrote:
When I run 'make check', it hangs sometimes.
I use gdb to attach lt-virsh, and the following is the backtrace: (gdb) thread 1 [Switching to thread 1 (Thread 0x7fc6c04d5800 (LWP 24099))]#0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041c0b3 in vshDeinit (ctl=0x7fff015f4570) at virsh.c:17262 #2 0x00000000004248d1 in main (argc=<value optimized out>, argv=0x7fff015f4728) at virsh.c:17608 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fc6c04d4700 (LWP 24138))]#0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 #1 0x00007fc6c075359c in virEventPollRunOnce () at util/event_poll.c:619 #2 0x00007fc6c07527d7 in virEventRunDefaultImpl () at util/event.c:247 #3 0x000000000041bea3 in vshEventLoop (opaque=0x7fff015f4570) at virsh.c:16800 #4 0x00007fc6c0764702 in virThreadHelper (data=<value optimized out>) at util/threads-pthread.c:157 #5 0x0000003bdce077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003bdc2e570d in clone () from /lib64/libc.so.6 (gdb)
I've seen this once, for the first time yesterday, but I can't see any obvious change in either virsh, or the event code that would have caused this to start happening in the past couple of days.
Hmm, I suspect this may be caused by
commit fd7e85ac6af833845aa0eb2526158c319800a0ae Author: Jiri Denemark <jdenemar@redhat.com> Date: Tue Oct 11 15:05:52 2011 +0200
virsh: Always run event loop
Since virsh already implements event loop, it has to also run it. So far the event loop was only running during virsh console command.
However, the commit added a special hack to prevent this from happening:
@@ -17080,6 +17101,16 @@ vshDeinit(vshControl *ctl) } virResetLastError();
+ if (ctl->eventLoopStarted) { + /* HACK: Add a dummy timeout to break event loop */ + int timer = virEventAddTimeout(-1, NULL, NULL, NULL); + if (timer != -1) + virEventRemoveTimeout(timer); + + virThreadJoin(&ctl->eventLoop); + ctl->eventLoopStarted = false; + } + return true; }
Perhaps it's not working as expected.
This smells like it, but something else triggered the problem, because that's really new, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Wed, Nov 30, 2011 at 11:48:16AM +0100, Jiri Denemark wrote:
On Wed, Nov 30, 2011 at 09:01:28 +0000, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 11:18:23AM +0800, Wen Congyang wrote:
When I run 'make check', it hangs sometimes.
I use gdb to attach lt-virsh, and the following is the backtrace: (gdb) thread 1 [Switching to thread 1 (Thread 0x7fc6c04d5800 (LWP 24099))]#0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041c0b3 in vshDeinit (ctl=0x7fff015f4570) at virsh.c:17262 #2 0x00000000004248d1 in main (argc=<value optimized out>, argv=0x7fff015f4728) at virsh.c:17608 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fc6c04d4700 (LWP 24138))]#0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 #1 0x00007fc6c075359c in virEventPollRunOnce () at util/event_poll.c:619 #2 0x00007fc6c07527d7 in virEventRunDefaultImpl () at util/event.c:247 #3 0x000000000041bea3 in vshEventLoop (opaque=0x7fff015f4570) at virsh.c:16800 #4 0x00007fc6c0764702 in virThreadHelper (data=<value optimized out>) at util/threads-pthread.c:157 #5 0x0000003bdce077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003bdc2e570d in clone () from /lib64/libc.so.6 (gdb)
I've seen this once, for the first time yesterday, but I can't see any obvious change in either virsh, or the event code that would have caused this to start happening in the past couple of days.
Hmm, I suspect this may be caused by
commit fd7e85ac6af833845aa0eb2526158c319800a0ae Author: Jiri Denemark <jdenemar@redhat.com> Date: Tue Oct 11 15:05:52 2011 +0200
virsh: Always run event loop
Since virsh already implements event loop, it has to also run it. So far the event loop was only running during virsh console command.
However, the commit added a special hack to prevent this from happening:
@@ -17080,6 +17101,16 @@ vshDeinit(vshControl *ctl) } virResetLastError();
+ if (ctl->eventLoopStarted) { + /* HACK: Add a dummy timeout to break event loop */ + int timer = virEventAddTimeout(-1, NULL, NULL, NULL); + if (timer != -1) + virEventRemoveTimeout(timer); + + virThreadJoin(&ctl->eventLoop); + ctl->eventLoopStarted = false; + } + return true; }
Perhaps it's not working as expected.
Ahhh, I had discounted that because the date was Oct 11, and I figured we would have seen it by now. But that's just your original commit date, the merge date was Oct 24th. So yeah, I reckon this must be the culprit Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 11/30/2011 04:40 AM, Daniel P. Berrange wrote:
Hmm, I suspect this may be caused by
commit fd7e85ac6af833845aa0eb2526158c319800a0ae Author: Jiri Denemark <jdenemar@redhat.com> Date: Tue Oct 11 15:05:52 2011 +0200
virsh: Always run event loop
Since virsh already implements event loop, it has to also run it. So far the event loop was only running during virsh console command.
Ahhh, I had discounted that because the date was Oct 11, and I figured we would have seen it by now. But that's just your original commit date, the merge date was Oct 24th. So yeah, I reckon this must be the culprit
I've been seeing this fairly often (about 25% of my 'make check' runs) since at least last Wednesday, on F16 when compiling at -O0; and the analysis of a race caused by not locking around ctl->quit seems like a reasonable culprit. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
At 11/30/2011 11:17 PM, Eric Blake Write:
On 11/30/2011 04:40 AM, Daniel P. Berrange wrote:
Hmm, I suspect this may be caused by
commit fd7e85ac6af833845aa0eb2526158c319800a0ae Author: Jiri Denemark <jdenemar@redhat.com> Date: Tue Oct 11 15:05:52 2011 +0200
virsh: Always run event loop
Since virsh already implements event loop, it has to also run it. So far the event loop was only running during virsh console command.
Ahhh, I had discounted that because the date was Oct 11, and I figured we would have seen it by now. But that's just your original commit date, the merge date was Oct 24th. So yeah, I reckon this must be the culprit
I've been seeing this fairly often (about 25% of my 'make check' runs) since at least last Wednesday, on F16 when compiling at -O0; and the analysis of a race caused by not locking around ctl->quit seems like a reasonable culprit.
This may be one reason. I think there is some bug in testdriver, and it will also cause 'make check' hang. Here is the backtrace when 'make check' hung: (gdb) info threads 2 Thread 0x7f22e81da700 (LWP 25242) 0x0000003bdce0dff4 in __lll_lock_wait () from /lib64/libpthread.so.0 * 1 Thread 0x7f22e81db800 (LWP 25227) 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041c193 in vshDeinit (ctl=0x7fff6098df20) at virsh.c:17506 #2 0x0000000000425251 in main (argc=<value optimized out>, argv=0x7fff6098e0d8) at virsh.c:17852 (gdb) thread 2 [Switching to thread 2 (Thread 0x7f22e81da700 (LWP 25242))]#0 0x0000003bdce0dff4 in __lll_lock_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0dff4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003bdce09328 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x0000003bdce091f7 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f22e84f6e9c in testDriverLock (timer=<value optimized out>, opaque=0x2192e10) at test/test_driver.c:127 #4 testDomainEventFlush (timer=<value optimized out>, opaque=0x2192e10) at test/test_driver.c:5515 #5 0x00007f22e8459a08 in virEventPollDispatchTimeouts () at util/event_poll.c:440 #6 virEventPollRunOnce () at util/event_poll.c:633 #7 0x00007f22e8458a27 in virEventRunDefaultImpl () at util/event.c:247 #8 0x000000000041bf83 in vshEventLoop (opaque=0x7fff6098df20) at virsh.c:17044 #9 0x00007f22e846a862 in virThreadHelper (data=<value optimized out>) at util/threads-pthread.c:157 #10 0x0000003bdce077f1 in start_thread () from /lib64/libpthread.so.0 #11 0x0000003bdc2e570d in clone () from /lib64/libc.so.6 According to the backtrace, lt-virsh is deadlock. Thanks Wen Congyang
On Wed, Nov 30, 2011 at 11:48:16AM +0100, Jiri Denemark wrote:
Hmm, I suspect this may be caused by
commit fd7e85ac6af833845aa0eb2526158c319800a0ae Author: Jiri Denemark <jdenemar@redhat.com> Date: Tue Oct 11 15:05:52 2011 +0200
virsh: Always run event loop
Since virsh already implements event loop, it has to also run it. So far the event loop was only running during virsh console command.
However, the commit added a special hack to prevent this from happening:
@@ -17080,6 +17101,16 @@ vshDeinit(vshControl *ctl) } virResetLastError();
+ if (ctl->eventLoopStarted) { + /* HACK: Add a dummy timeout to break event loop */ + int timer = virEventAddTimeout(-1, NULL, NULL, NULL); + if (timer != -1) + virEventRemoveTimeout(timer); + + virThreadJoin(&ctl->eventLoop); + ctl->eventLoopStarted = false; + } + return true;
I think the problem may lie a little bit further up static bool vshDeinit(vshControl *ctl) { ctl->quit = true; vshReadlineDeinit(ctl); vshCloseLogFile(ctl); VIR_FREE(ctl->name); if (ctl->conn) { int ret; if ((ret = virConnectClose(ctl->conn)) != 0) { vshError(ctl, _("Failed to disconnect from the hypervisor, %d leaked reference(s)"), ret); } } virResetLastError(); if (ctl->eventLoopStarted) { /* HACK: Add a dummy timeout to break event loop */ int timer = virEventAddTimeout(-1, NULL, NULL, NULL); Now look at the event loop thread: static void vshEventLoop(void *opaque) { vshControl *ctl = opaque; while (!ctl->quit) { if (virEventRunDefaultImpl() < 0) { virshReportError(ctl); } } } Neither the read of ctl->quit, nor the write of ctl->quit are protected by any locking. While you have assigned to ctl->quit before adding the dummy function, I'm not convinced that is sufficient, because in the absence of any thread synchronization point, the compiler is free to reorder your assignment to occur later. In addition, the data is not neccessarily coherant across threads. IMHO, the read/write of ctl->quit needs to be protected by a mutex. Regrads, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Nov 30, 2011 at 11:54:55 +0000, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 11:48:16AM +0100, Jiri Denemark wrote: static bool vshDeinit(vshControl *ctl) { ctl->quit = true; vshReadlineDeinit(ctl); vshCloseLogFile(ctl); VIR_FREE(ctl->name); if (ctl->conn) { int ret; if ((ret = virConnectClose(ctl->conn)) != 0) { vshError(ctl, _("Failed to disconnect from the hypervisor, %d leaked reference(s)"), ret); } } virResetLastError();
if (ctl->eventLoopStarted) { /* HACK: Add a dummy timeout to break event loop */ int timer = virEventAddTimeout(-1, NULL, NULL, NULL);
Now look at the event loop thread:
static void vshEventLoop(void *opaque) { vshControl *ctl = opaque;
while (!ctl->quit) { if (virEventRunDefaultImpl() < 0) { virshReportError(ctl); } } }
Neither the read of ctl->quit, nor the write of ctl->quit are protected by any locking. While you have assigned to ctl->quit before adding the dummy function, I'm not convinced that is sufficient, because in the absence of any thread synchronization point, the compiler is free to reorder your assignment to occur later. In addition, the data is not neccessarily coherant across threads. IMHO, the read/write of ctl->quit needs to be protected by a mutex.
Yeah, you're right. I seem to keep forgetting about this memory barrier "side effect" of mutexes, which in fact is the only thing we need here :-) Jirka
On Wed, Nov 30, 2011 at 09:01:28AM +0000, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 11:18:23AM +0800, Wen Congyang wrote:
When I run 'make check', it hangs sometimes.
I use gdb to attach lt-virsh, and the following is the backtrace: (gdb) thread 1 [Switching to thread 1 (Thread 0x7fc6c04d5800 (LWP 24099))]#0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041c0b3 in vshDeinit (ctl=0x7fff015f4570) at virsh.c:17262 #2 0x00000000004248d1 in main (argc=<value optimized out>, argv=0x7fff015f4728) at virsh.c:17608 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fc6c04d4700 (LWP 24138))]#0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 #1 0x00007fc6c075359c in virEventPollRunOnce () at util/event_poll.c:619 #2 0x00007fc6c07527d7 in virEventRunDefaultImpl () at util/event.c:247 #3 0x000000000041bea3 in vshEventLoop (opaque=0x7fff015f4570) at virsh.c:16800 #4 0x00007fc6c0764702 in virThreadHelper (data=<value optimized out>) at util/threads-pthread.c:157 #5 0x0000003bdce077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003bdc2e570d in clone () from /lib64/libc.so.6 (gdb)
I've seen this once, for the first time yesterday, but I can't see any obvious change in either virsh, or the event code that would have caused this to start happening in the past couple of days.
Same yesterday for me, first time too, on F14, I was blaming my system as I got an oops earlier, but apparently that's not it ! I got it again, and it's the virsh-synopsis test which fails to finish. I had to try 4 time before reproducing it... Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 2011年11月30日 19:28, Daniel Veillard wrote:
On Wed, Nov 30, 2011 at 09:01:28AM +0000, Daniel P. Berrange wrote:
On Wed, Nov 30, 2011 at 11:18:23AM +0800, Wen Congyang wrote:
When I run 'make check', it hangs sometimes.
I use gdb to attach lt-virsh, and the following is the backtrace: (gdb) thread 1 [Switching to thread 1 (Thread 0x7fc6c04d5800 (LWP 24099))]#0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003bdce0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041c0b3 in vshDeinit (ctl=0x7fff015f4570) at virsh.c:17262 #2 0x00000000004248d1 in main (argc=<value optimized out>, argv=0x7fff015f4728) at virsh.c:17608 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fc6c04d4700 (LWP 24138))]#0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x0000003bdc2dc053 in poll () from /lib64/libc.so.6 #1 0x00007fc6c075359c in virEventPollRunOnce () at util/event_poll.c:619 #2 0x00007fc6c07527d7 in virEventRunDefaultImpl () at util/event.c:247 #3 0x000000000041bea3 in vshEventLoop (opaque=0x7fff015f4570) at virsh.c:16800 #4 0x00007fc6c0764702 in virThreadHelper (data=<value optimized out>) at util/threads-pthread.c:157 #5 0x0000003bdce077f1 in start_thread () from /lib64/libpthread.so.0 #6 0x0000003bdc2e570d in clone () from /lib64/libc.so.6 (gdb)
I've seen this once, for the first time yesterday, but I can't see any obvious change in either virsh, or the event code that would have caused this to start happening in the past couple of days.
Same yesterday for me, first time too, on F14, I was blaming my system as I got an oops earlier, but apparently that's not it ! I got it again, and it's the virsh-synopsis test which fails to finish. I had to try 4 time before reproducing it...
Daniel
I see the problem too, generally it will hangs when testing "virsh schedinfo". Regards, Osier
participants (6)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Jiri Denemark -
Osier Yang -
Wen Congyang