From patchwork Mon May 27 14:24:59 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Lieven X-Patchwork-Id: 246610 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id AF8D42C02F7 for ; Tue, 28 May 2013 00:25:32 +1000 (EST) Received: from localhost ([::1]:39411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgyMc-0002Bf-Bx for incoming@patchwork.ozlabs.org; Mon, 27 May 2013 10:25:30 -0400 Received: from eggs.gnu.org ([208.118.235.92]:56753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgyME-00028Q-Nd for qemu-devel@nongnu.org; Mon, 27 May 2013 10:25:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgyM9-00025L-DQ for qemu-devel@nongnu.org; Mon, 27 May 2013 10:25:06 -0400 Received: from ssl.dlhnet.de ([91.198.192.8]:33538 helo=ssl.dlh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgyM9-00024b-2l for qemu-devel@nongnu.org; Mon, 27 May 2013 10:25:01 -0400 Received: from localhost (localhost [127.0.0.1]) by ssl.dlh.net (Postfix) with ESMTP id DD0E414A781; Mon, 27 May 2013 16:24:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at ssl.dlh.net Received: from ssl.dlh.net ([127.0.0.1]) by localhost (ssl.dlh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPlIOI7xCgTK; Mon, 27 May 2013 16:24:59 +0200 (CEST) Received: from [172.21.12.60] (unknown [82.141.1.226]) by ssl.dlh.net (Postfix) with ESMTPSA id 0C9661437F4; Mon, 27 May 2013 16:24:59 +0200 (CEST) Message-ID: <51A36CBB.7030502@dlhnet.de> Date: Mon, 27 May 2013 16:24:59 +0200 From: Peter Lieven User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Oliver Francke References: <1369227018-27837-1-git-send-email-stefanha@redhat.com> <51A2FA0E.4090906@dlhnet.de> <070AF036-B048-4CBA-ACCB-E419AFE7745C@filoo.de> In-Reply-To: <070AF036-B048-4CBA-ACCB-E419AFE7745C@filoo.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 91.198.192.8 Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Subject: Re: [Qemu-devel] [PATCH] rtl8139: flush queued packets when RxBufPtr is written X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On 27.05.2013 16:07, Oliver Francke wrote: > Well, > > Am 27.05.2013 um 08:15 schrieb Peter Lieven : > >> 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 to my qemu-1.2.0 build. I think this might be why I see this. have to tried to patch qemu-1.2.0 with something like this? Peter > > Oliver. > >> 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 >>> Signed-off-by: Stefan Hajnoczi >>> --- >>> 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); >>> } --- a/hw/rtl8139.c +++ b/hw/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(&s->nic->nc); + DPRINTF(" CAPR write: rx buffer length %d head 0x%04x read 0x%04x\n", s->RxBufferSize, s->RxBufAddr, s->RxBufPtr); }