Re: [Qemu-devel] [PATCH] rtl8139: flush queued packets when RxBufPtr is written

[Peter Lieven]

On 27.05.2013 17:29, Stefan Hajnoczi wrote:
> 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 <address@hidden>:
> > >
> > > > 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 <address@hidden>
> Date:   Mon Aug 20 13:35:23 2012 +0100
>
>      net: do not report queued packets as sent
This was also in the series I cherry-picked for my 1.2.0 build. So its likely I 
hit the same bug.

Thank you,
Peter