From mboxrd@z Thu Jan 1 00:00:00 1970 From: david ahern Subject: Re: still seeing network freezes with rtl8139 nic Date: Sun, 24 Feb 2008 12:49:35 -0700 Message-ID: <47C1CA4F.3020605@cisco.com> References: <47BDC414.30301@cisco.com> <47C14371.9040405@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Avi Kivity Return-path: In-Reply-To: <47C14371.9040405@qumranet.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org I've run a lot more tests: - with the -no-kvm-irqchip option the vm eventully stops responding to network or console, - with the -no-kvm option the performance is so bad I cannot get our ap up and running so the results are inconclusive, - I've tried the e1000 and pcnet nic models and both showed the network lockup; with the ne2k_pci nic I did not see dropped packets and the network never locked up in 12+ hours, but system CPU time was 10% higher than when the rtl8139 nic was working - if I remove the "if (!change) return" optimization from pci_set_irq the rtl8139 nic worked fine for 16+ hours. I'm not recommending this as a fix, just confirming that the problem goes away. - I tried adding a thread mutex to the rtl8139 device model around accesses to the RTL8139State data, but the network still locked up. david Avi Kivity wrote: > david ahern wrote: >> I know this issue has been discussed on this list before, but I am still >> experiencing network freezes in a guest that requires a restart to clear. When >> the network freezes in the guest I no longer see the network interrupts counter >> incrementing (i.e., the eth0 counter in /proc/interrupts in the guest). Using >> the crash utility, I verified that the interrupt is still enabled on the guest >> side and that no interrupts are pending. This suggests that the interrupts are >> not getting delivered to the VM. >> >> > > [...] > >> I am continuing to look into the irq processing on the kvm/qemu side. I'd like >> to know if anyone has suggestions on what to look at. This is my first foray >> into the kvm and qemu code, and it's a lot to take in all at once. >> >> > > Standard procedure is to run with -no-kvm and -no-kvm-irqchip, to see if > the problem is in qemu proper, the in-kernel irq handling, or the rest > of kvm. > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/