From: david ahern <daahern@cisco.com>
To: Avi Kivity <avi@qumranet.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>
Subject: Re: still seeing network freezes with rtl8139 nic
Date: Sun, 24 Feb 2008 12:49:35 -0700 [thread overview]
Message-ID: <47C1CA4F.3020605@cisco.com> (raw)
In-Reply-To: <47C14371.9040405@qumranet.com>
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/
next prev parent reply other threads:[~2008-02-24 19:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-21 18:33 still seeing network freezes with rtl8139 nic david ahern
2008-02-24 10:14 ` Avi Kivity
2008-02-24 19:49 ` david ahern [this message]
2008-02-25 8:54 ` Avi Kivity
2008-02-25 16:11 ` david ahern
2008-02-25 17:06 ` david ahern
2008-02-25 17:19 ` Avi Kivity
2008-02-26 4:57 ` david ahern
2008-02-26 9:19 ` Avi Kivity
2008-02-26 14:41 ` Avi Kivity
2008-02-26 14:55 ` david ahern
2008-02-26 14:50 ` david ahern
2008-02-26 15:07 ` Avi Kivity
2008-03-04 18:05 ` Eckersid SIlapaswang
2008-03-05 15:04 ` david ahern
2008-03-05 17:14 ` Avi Kivity
2008-03-05 18:33 ` david ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47C1CA4F.3020605@cisco.com \
--to=daahern@cisco.com \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox