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