From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcmoH-0005vB-EE for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:54:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcmoG-0005uy-1c for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:54:05 -0400 Received: from [199.232.76.173] (port=35752 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcmoF-0005uo-Vc for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:54:03 -0400 Received: from rv-out-0708.google.com ([209.85.198.248]:10510) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KcmoF-00079h-Hu for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:54:03 -0400 Received: by rv-out-0708.google.com with SMTP id f25so1377617rvb.22 for ; Mon, 08 Sep 2008 12:54:02 -0700 (PDT) Message-ID: Date: Mon, 8 Sep 2008 23:54:01 +0400 From: "Igor Kovalenko" Subject: Re: [Qemu-devel] 8139cp problems - steps to reproduce In-Reply-To: <20080908075759.GA27882@develbox.linuxbox.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080908075759.GA27882@develbox.linuxbox.cz> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: nikola.ciprich@linuxbox.cz, KVM list , lfarkas@lfarkas.org On Mon, Sep 8, 2008 at 11:57 AM, Nikola Ciprich wrote: > Hello Avi and everybody, > > (and in advance, sorry for cross-posting). > > As it was already reported, some people (including me :)) have problems > with network getting stuck from time to time in KVM guests. > > According to http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=4563&start=0&st=0&sk=t&sd=a&sid=fcf252234991e017919ca7d0eb3799a3 > the problem is maybe not KVM speciffic. > > I can confirm that the problem seems to be occuring after transmitting few gigabytes of data, > so it can be simply reproduced by starting KVM guest, mounting some NFS in it, and then > starting shell loop dd if=/mnt/nfs/bigimage.iso of=/dev/zero > after some runs (in my case usually tens of GB), the problem occurs: > [ 2159.614496] NETDEV WATCHDOG: eth0: transmit timed out > [ 2159.614537] eth0: Transmit timeout, status d 2b 15 80ff > > The status " d 2b 15 80ff" is always the same, on all testing machines > which according to 8139cp.c means > > Command register=d receiver enabled, transmitter enabled, buffer empty > C+ command register=2b C+ mode receiver enabled, transmitter enabled, receive checksum offloading enabled, unsupported pci multiple r/w enabled > Interrupt status=15 receiver overflow! tx ok,rx ok > Interrupt mask=80ff > So does somebody have an idea on where the problem could be? Of course I'll be glad to (try) to help > debugging... If it is not guest networking... please check if rx missed is not zero (no idea how, probably with ethtool or with netstat -i) You can also try enabling overflow debugging statements near lines where s->IntrStatus |= RxOverflow ... there are 3 of these. There is quite low probability that rtl8139 should not set RxOK if it has overflow, or that guest driver does not expect it in that combination (which seems to be rather valid in case card received full set of descriptors space of data and missed last packet before driver was able to read and vacate some buffers.) -- Kind regards, Igor V. Kovalenko