All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark McLoughlin <markmc@redhat.com>
To: Emmanuel Lacour <elacour@easter-eggs.com>
Cc: kvm@vger.kernel.org
Subject: Re: virtio_net hang
Date: Fri, 14 Nov 2008 18:26:44 +0000	[thread overview]
Message-ID: <1226687204.9332.113.camel@blaa> (raw)
In-Reply-To: <20081114092339.GC11961@easter-eggs.com>

On Fri, 2008-11-14 at 10:23 +0100, Emmanuel Lacour wrote:
> On Thu, Nov 13, 2008 at 04:24:52PM +0100, Emmanuel Lacour wrote:
> > On Thu, Nov 13, 2008 at 03:12:33PM +0000, Mark McLoughlin wrote:
> > > The fact that re-loading the virtio_net driver fixes things up makes me
> > > suspect you've found a bug in the virtio_net driver, rather than e.g. a
> > > bug in the kvm-userspace side.
> > > 
> > > To try and narrow down what's happening, when the interface has hung,
> > > try:
> > > 
> > >   - tcpdump on both eth0 in the guest and the tap device on the host 
> > >     (tap5 in your example)
> > > 
> 
> 
> On eth0 I see echo requests, but _no_ echo replies
> On tap5 I see echo requests _and_ echo replies

Okay, so the guest isn't receiving packets.

> > >   - look for anything unusual in the stats for both those interfaces,
> > >      e.g. /proc/net/dev, netstat -s etc.
> > > 
> 
> Comparing with other guest without problems, the only difference is that this
> tap (and only this one) reports "overruns":
> 
> tap5      Link encap:Ethernet  HWaddr 00:FF:AD:53:76:25  
>           inet6 addr: fe80::2ff:adff:fe53:7625/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:717737621 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:636626720 errors:0 dropped:0 overruns:317 carrier:0
>           collisions:0 txqueuelen:500 
>           RX bytes:368973099756 (343.6 GiB)  TX bytes:217917073227 (202.9 GiB)
> 
> overruns seems to happen just when there is "hang", it doesn't seems to
> increase when network is working properly.

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.

Cheers,
Mark.


  reply	other threads:[~2008-11-14 18:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-13 12:27 virtio_net hang Emmanuel Lacour
2008-11-13 13:04 ` Daniel P. Berrange
2008-11-13 13:15   ` Emmanuel Lacour
2008-11-13 15:12 ` Mark McLoughlin
2008-11-13 15:24   ` Emmanuel Lacour
2008-11-14  9:23     ` Emmanuel Lacour
2008-11-14 18:26       ` Mark McLoughlin [this message]
2008-11-18 18:37         ` Emmanuel Lacour
2008-11-18 18:48           ` Emmanuel Lacour
2008-11-19 13:13           ` Mark McLoughlin
2008-11-19 19:03             ` Mark McLoughlin
2008-11-20 11:36               ` Emmanuel Lacour
2008-11-21  8:38                 ` Emmanuel Lacour
2008-11-22 14:20                   ` Emmanuel Lacour
2008-11-21 14:44                 ` Guido Günther
2008-11-20 11:34             ` Emmanuel Lacour
2008-11-13 18:27 ` Fabio Coatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1226687204.9332.113.camel@blaa \
    --to=markmc@redhat.com \
    --cc=elacour@easter-eggs.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.