On Mon, May 27, 2013 at 04:24:59PM +0200, Peter Lieven wrote:
> On 27.05.2013 16:07, Oliver Francke wrote:
> >Well,
> >
> >Am 27.05.2013 um 08:15 schrieb Peter Lieven <lieven-li...@dlhnet.de>:
> >
> >>Hi all,
> >>
> >>I ocassionally have seen a probably related problem in the past. It mainly
> >>happend with rtl8139 under
> >>WinXP where we most likely use rtl8139 due to lack of shipped e1000 drivers.
> >>
> >>My question is if you see increasing dropped packets on the tap device if
> >>this problem occurs?
> >>
> >>tap36 Link encap:Ethernet HWaddr b2:84:23:c0:e2:c0
> >> inet6 addr: fe80::b084:23ff:fec0:e2c0/64 Scope:Link
> >> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
> >> RX packets:5816096 errors:0 dropped:0 overruns:0 frame:0
> >> TX packets:3878744 errors:0 dropped:13775 overruns:0 carrier:0
> >> collisions:0 txqueuelen:500
> >> RX bytes:5161769434 (5.1 GB) TX bytes:380415916 (380.4 MB)
> >>
> >>In my case as well the only option to recover without shutting down the
> >>whole vServer is Live Migration
> >>to another Node.
> >>
> >ACK, tried it and every network-devices might have been re-created into a
> >defined state qemu-wise.
> >
> >>However, I also see this problem under qemu-kvm-1.2.0 while Oliver reported
> >>it does not happen there.
> >>
> >Neither me nor any affected customers have ever seen such failures in
> >qemu-1.2.0, so this was my last-known-good ;)
> I cherry-picked
>
> net: add receive_disabled logic to iov delivery path
This one exposes the bug that Oliver reported:
commit a9d8f7b1c41a8a346f4cf5a0c6963a79fbd1249e
Author: Stefan Hajnoczi <stefa...@linux.vnet.ibm.com>
Date: Mon Aug 20 13:35:23 2012 +0100
net: do not report queued packets as sent
