From: Peter Lieven <lieven-lists@dlhnet.de>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: oliver.francke@filoo.de, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] rtl8139: flush queued packets when RxBufPtr is written
Date: Mon, 27 May 2013 08:15:42 +0200 [thread overview]
Message-ID: <51A2FA0E.4090906@dlhnet.de> (raw)
In-Reply-To: <1369227018-27837-1-git-send-email-stefanha@redhat.com>
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.
However, I also see this problem under qemu-kvm-1.2.0 while Oliver reported it does not happen there.
Thank you,
Peter
On 22.05.2013 14:50, Stefan Hajnoczi wrote:
> Net queues support efficient "receive disable". For example, tap's file
> descriptor will not be polled while its peer has receive disabled. This
> saves CPU cycles for needlessly copying and then dropping packets which
> the peer cannot receive.
>
> rtl8139 is missing the qemu_flush_queued_packets() call that wakes the
> queue up when receive becomes possible again.
>
> As a result, the Windows 7 guest driver reaches a state where the
> rtl8139 cannot receive packets. The driver has actually refilled the
> receive buffer but we never resume reception.
>
> The bug can be reproduced by running a large FTP 'get' inside a Windows
> 7 guest:
>
> $ qemu -netdev tap,id=tap0,...
> -device rtl8139,netdev=tap0
>
> The Linux guest driver does not trigger the bug, probably due to a
> different buffer management strategy.
>
> Reported-by: Oliver Francke <oliver.francke@filoo.de>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> hw/net/rtl8139.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/hw/net/rtl8139.c b/hw/net/rtl8139.c
> index 9369507..7993f9f 100644
> --- a/hw/net/rtl8139.c
> +++ b/hw/net/rtl8139.c
> @@ -2575,6 +2575,9 @@ static void rtl8139_RxBufPtr_write(RTL8139State *s, uint32_t val)
> /* this value is off by 16 */
> s->RxBufPtr = MOD2(val + 0x10, s->RxBufferSize);
>
> + /* more buffer space may be available so try to receive */
> + qemu_flush_queued_packets(qemu_get_queue(s->nic));
> +
> DPRINTF(" CAPR write: rx buffer length %d head 0x%04x read 0x%04x\n",
> s->RxBufferSize, s->RxBufAddr, s->RxBufPtr);
> }
next prev parent reply other threads:[~2013-05-27 6:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-22 12:50 [Qemu-devel] [PATCH] rtl8139: flush queued packets when RxBufPtr is written Stefan Hajnoczi
2013-05-22 12:53 ` Andreas Färber
2013-05-22 13:33 ` Stefan Hajnoczi
2013-05-24 14:34 ` Stefan Hajnoczi
2013-05-27 6:15 ` Peter Lieven [this message]
2013-05-27 8:32 ` Stefan Hajnoczi
2013-05-27 10:19 ` Peter Lieven
2013-05-27 14:07 ` Oliver Francke
2013-05-27 14:24 ` Peter Lieven
2013-05-27 15:29 ` Stefan Hajnoczi
2013-05-28 6:27 ` Peter Lieven
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=51A2FA0E.4090906@dlhnet.de \
--to=lieven-lists@dlhnet.de \
--cc=oliver.francke@filoo.de \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).