On Wed, 2008-07-16 at 15:50 +0100, Mark McLoughlin wrote:
> The race was observed with a modified kvm-userspace when
> running a guest under heavy network load. When it occurs,
> KVM never sees another SIGALRM signal because although
> the signal is queued up the appropriate bit is never set
> in the pending mask. Manually sending the process a SIGALRM
> kicks it out of this state.
I should clarify what I mean by "modified kvm-userspace". Basically, I
was trying out a suggestion of Marcelo's to drop the global qemu mutex
when reading GSO packets from a tap device i.e.
@@ -4299,7 +4299,9 @@ static void tap_send(void *opaque)
sbuf.buf = s->buf;
s->size = getmsg(s->fd, NULL, &sbuf, &f) >=0 ? sbuf.len : -1;
#else
+ kvm_mutex_unlock();
s->size = read(s->fd, s->buf, sizeof(s->buf));
+ kvm_mutex_lock();
It seems to work fine, but more on that later ... important thing is
that if people see a hard-to-reproduce condition where things seem to
slow down or lock up, try manually doing a "kill -ALRM $(qemu)" and if
that fixes it, then you're probably seeing this bug.
Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
