On Tue, 2008-11-18 at 19:37 +0100, Emmanuel Lacour wrote: > On Fri, Nov 14, 2008 at 06:26:44PM +0000, Mark McLoughlin wrote: > > > > Right, the tap device tx queue is full because kvm-userspace isn't > > reading packets from it. > > > > This could be because kvm-userspace has just stopped noticing that > > there's data available from the tapfd or because virtio_net in the guest > > has stopped noticing that packets are available in the ring. > > > > One thing you could easily check is whether: > > > > ip link set eth0 down > > ip link set eth0 up > > > > in the host is sufficient to fix it? If it is, then it points to a guest > > driver issue. > > > > I made the test, putting link down then up fix it.
Thanks, that's very interesting. Since bringing the interface up and down basically just causes the driver to re-schedule itself with NAPI, all I can see as a possibility is that we somehow (e.g. a race condition) had gotten ourselves into a state where we have rx ring interrupts disabled and we're not scheduled with NAPI. We synchronise around the NAPI_STATE_SCHED bit with atomic operations and all the logic looks correct ... so I'm stumped, really. Is it possible for you to try a newer guest kernel? 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
