All of lore.kernel.org
 help / color / mirror / Atom feed
From: Emmanuel Lacour <elacour@easter-eggs.com>
To: kvm@vger.kernel.org
Subject: Re: virtio_net hang
Date: Fri, 14 Nov 2008 10:23:39 +0100	[thread overview]
Message-ID: <20081114092339.GC11961@easter-eggs.com> (raw)
In-Reply-To: <20081113152452.GI14254@easter-eggs.com>

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

> >   - 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.


> >   - strace the /usr/bin/kvm process
> > 

Unfortunatly I was unable to do this because I can't reproduce the problem on a
test VM and I can't leave this VM with a non working network for analysis
because of production so I have a script which pings and restart
module/interface when needed.


  reply	other threads:[~2008-11-14  9:23 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 [this message]
2008-11-14 18:26       ` Mark McLoughlin
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=20081114092339.GC11961@easter-eggs.com \
    --to=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.