From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdJc8-0005Iv-I7 for qemu-devel@nongnu.org; Wed, 10 Sep 2008 02:55:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdJc7-0005IC-1c for qemu-devel@nongnu.org; Wed, 10 Sep 2008 02:55:44 -0400 Received: from [199.232.76.173] (port=33186 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdJc6-0005I7-NG for qemu-devel@nongnu.org; Wed, 10 Sep 2008 02:55:42 -0400 Received: from mx20.gnu.org ([199.232.41.8]:37102) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KdJc5-00069l-SI for qemu-devel@nongnu.org; Wed, 10 Sep 2008 02:55:42 -0400 Received: from gwu.lbox.cz ([62.245.111.132]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KdJbx-0001Fw-Sa for qemu-devel@nongnu.org; Wed, 10 Sep 2008 02:55:34 -0400 Date: Wed, 10 Sep 2008 08:55:26 +0200 From: Nikola Ciprich Subject: Re: [Qemu-devel] 8139cp problems - steps to reproduce Message-ID: <20080910065526.GA6863@develbox.linuxbox.cz> References: <20080908075759.GA27882@develbox.linuxbox.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Kovalenko Cc: nikola.ciprich@linuxbox.cz, qemu-devel@nongnu.org, KVM list , lfarkas@lfarkas.org On Mon, Sep 08, 2008 at 11:54:01PM +0400, Igor Kovalenko wrote: Hi Igor, I'm using bridged TAP device. Running ethtool -S eth0 (when it's still working) shows increasing number of rx_err (rx_fifo is also increasing, dunno what that means). tx_ok, rx_ok are also increasing of course. Then when the network hangs, tx_ok, rx_ok stop increasing, and only rx_err and rx_fifo keep growing... rtl8139-diag says among others: Transmitter enabled with NONSTANDARD! settings, maximum burst 1024 bytes. dunno if this is related... when trying 2.6.26 x86-32 guest, i also got this: [ 3719.662726] eth0: Transmit timeout, status d 2b 15 80ff [ 3719.662968] ------------[ cut here ]------------ [ 3719.662970] WARNING: at net/sched/sch_generic.c:223 dev_watchdog+0xde/0xf0() [ 3719.662972] Modules linked in: nfs lockd sunrpc ipv6 dm_mod sbshc container button battery ac i2c_piix4 i2c_core 8139cp mii bitrev crc32 piix pata_acpi ide_pci_generic ata_piix ata_generic libata sd_mod scsi_mod dock ide_disk ide_core ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: x_tables] [ 3719.663087] Pid: 0, comm: swapper Not tainted 2.6.26lb.01 #1 [ 3719.663091] [] warn_on_slowpath+0x5f/0x90 [ 3719.663112] [] cp_interrupt+0x25c/0x440 [8139cp] [ 3719.663123] [] getnstimeofday+0x3d/0xe0 [ 3719.663136] [] ack_ioapic_quirk_irq+0x9/0x80 [ 3719.663143] [] handle_fasteoi_irq+0x8c/0xe0 [ 3719.663151] [] do_IRQ+0x40/0x70 [ 3719.663155] [] nommu_map_single+0x2a/0x60 [ 3719.663158] [] dev_watchdog+0x0/0xf0 [ 3719.663161] [] common_interrupt+0x23/0x28 [ 3719.663164] [] dev_watchdog+0x0/0xf0 [ 3719.663168] [] dev_watchdog+0xde/0xf0 [ 3719.663171] [] run_timer_softirq+0x116/0x180 [ 3719.663179] [] __do_softirq+0x72/0xf0 [ 3719.663183] [] do_softirq+0x37/0x40 [ 3719.663186] [] irq_exit+0x57/0x70 [ 3719.663189] [] smp_apic_timer_interrupt+0x58/0x90 [ 3719.663193] [] rcu_pending+0x37/0x50 [ 3719.663195] [] default_idle+0x0/0x40 [ 3719.663210] [] apic_timer_interrupt+0x28/0x30 [ 3719.663212] [] default_idle+0x0/0x40 [ 3719.663216] [] default_idle+0x2e/0x40 [ 3719.663219] [] cpu_idle+0x53/0xc0 [ 3719.663224] ======================= [ 3719.663225] ---[ end trace a8aacd1e409fdad8 ]--- maybe it could help? > On Mon, Sep 8, 2008 at 11:57 AM, Nikola Ciprich wrote: > > 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 > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- ------------------------------------- Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: servis@linuxbox.cz -------------------------------------