From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdM6s-0001xD-AB for qemu-devel@nongnu.org; Wed, 10 Sep 2008 05:35:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdM6p-0001wp-Qd for qemu-devel@nongnu.org; Wed, 10 Sep 2008 05:35:36 -0400 Received: from [199.232.76.173] (port=52078 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdM6p-0001wf-2D for qemu-devel@nongnu.org; Wed, 10 Sep 2008 05:35:35 -0400 Received: from gwu.lbox.cz ([62.245.111.132]:42104) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KdM6o-0004pK-PV for qemu-devel@nongnu.org; Wed, 10 Sep 2008 05:35:35 -0400 Date: Wed, 10 Sep 2008 11:35:27 +0200 From: Nikola Ciprich Subject: Re: [Qemu-devel] 8139cp problems - steps to reproduce Message-ID: <20080910093527.GB6863@develbox.linuxbox.cz> References: <20080908075759.GA27882@develbox.linuxbox.cz> <20080910065526.GA6863@develbox.linuxbox.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080910065526.GA6863@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: Igor Kovalenko Cc: nikola.ciprich@linuxbox.cz, qemu-devel@nongnu.org, KVM list , lfarkas@lfarkas.org Hello one more time, I've just found some older thread on the topic, and it concluded that disabling APIC fixes the problem. I tried, and ... it works! So as workaround, it's OK for me now, but I guess this should still be considered a bug... If I could provide any help in fixing this, please let me know... regards nik On Wed, Sep 10, 2008 at 08:55:26AM +0200, Nikola Ciprich wrote: > 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 > ------------------------------------- > -- > 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 -------------------------------------